Ehsan Akhgari writes: > On 2015-04-27 9:54 PM, Trevor Saunders wrote: >> On Mon, Apr 27, 2015 at 09:07:51PM -0400, Ehsan Akhgari wrote: >>> On Mon, Apr 27, 2015 at 5:45 PM, Trevor Saunders <tbsau...@tbsaunde.org> >>> wrote: >>> >>>> I believe we have some cases in the tree where a virtual function >>>> doesn't override but is final so you need to write virtual final. I >>>> believe one of those cases may be so a function can be called indirectly >>>> from outside libxul, and another might be to prevent people using some >>>> cc macros incorrectly. >>>> >>> >>> Any chance you could point us to those functions, please? >> >> http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsCycleCollectionParticipant.h#548 > > Hmm, we can probably make an exception for this one.
(I assume below that you are proposing handling these through method-specific exceptions.) >> 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? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
