[webkit-dev] 'final' class specifier and 'final' method specifier

[Fujii Hironori]

On Fri, Dec 21, 2018 at 5:02 AM Konstantin Tokarev <annulen at yandex.ru>
wrote:

> >
> > On Thu, Dec 20, 2018 at 7:42 AM <Ross.Kirsling at sony.com> wrote:
> >> In that case, I'll point out that C++ Core Guidelines has a rule
> "Virtual functions should specify exactly one of virtual, override, or
> final".
> >> (
> http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override)
> >>
> >> Their tl;dr:
> >> "
> >>         • virtual means exactly and only “this is a new virtual
> function.”
> >>         • override means exactly and only “this is a non-final
> overrider.”
> >>         • final means exactly and only “this is a final overrider.”
> >> "
> >>
> >> FWIW, they also have a rule "Use final sparingly" with the note that
> "Claims of performance improvements from final should be substantiated."
> >> (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-final)
> >
> > C.128 is a same rule with the current WebKit coding style guidelines.
> > But, I think C.128 makes sense with C.139.
> > C.139 is against to Bug 192844.
> > After Bug 192844 update, we will have a lot of 'final' classes, not
> sparignly.
>
> Do you have an idea how to automate this? Otherwise we'll never reach the
> state where all leaf classes are final, because doing it manually will
> take lots of
> time, and I see no way to enforce the rule in new code
>
>
 I don't have such intelligent plan. I don't like the divergence
between WebKit Code Style Guidelines and WebKit source code. I've
often got review feedbacks that I should modernize the code
around my change. I'm going to change them manually, and all
patches will be checked by reviewer's eyes. There is a previous
such effort.

Bug 159802 – Add final keyword to WebCore/svg classes
https://bugs.webkit.org/show_bug.cgi?id=159802


It seems that I shouldn't change the current 'final' method specifier rule
of WebKit.
Then, I think the sentences should be revised such like C.128.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20181221/2679e019/attachment.html>