On 2015-04-29 9:16 PM, Karl Tomlinson wrote:
and this one isn't final, but we could make it final if the tu will be
built into libxul (because then devirtualization is fine)
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDocument.h#1287
I'm not sure why that function is virtual. If it's just in order
to make it possible to call it through a vtable from outside of
libxul, I'm not sure why we need to treat it differently than
other XPCOM APIs for example. If this is not used outside of
libxul, we can probably make it non-virtual.
XPCOM APIs are usually abstract interfaces and so not final.
final could be removed and have valid code, but may be a useful
optimization or enforcement of intent.
virtual final seems necessary for some use cases, and there is no
redundancy.
Is there a need to ban this usage?
The point is that there are *very few* use cases. Right now it seems
that there is only one place in mozilla-central where we use a
non-overriding virtual function that is also final, and that is a
function that is never called by anybody. In almost every other case,
such a method would just be devirtualized. The case ththat Trevor
mentioned above (using a non-virtual function for internal code but
allowing external code to access it too) is easily served by a virtual
non-final function that wraps a non-virtual one that the internal code uses.
The point of having a coding style is to have it prescribe what is
desirable in 99% of the cases, not prescribe something that works for
every single edge case that most people should never have to use. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
