sfantao added a comment. In http://reviews.llvm.org/D18172#471861, @jlebar wrote:
> Alexey, it seems that you're asking for "final" on all classes that are not > inherited from. Forgive my ignorance, but would you mind pointing me to the > document that talks about our position on "final" in LLVM source? I don't > see it in the style guide, but I may be missing something. > > The style guide does talk a good bit about writing concise and generally > not-misleading code. My concern is that adding "final" everywhere paints an > inaccurate picture and will mislead readers. Specifically, "final" is useful > as a signal to readers that a class cannot safely be inherited from. "Don't > even think about it, buster." But here we're adding "final" to a lot of > classes that, as far as I can tell, aren't distinctive except in that they > have no subclasses today. The problem with this is that, if we use "final" > in this way, it dilutes the first "don't even try" meaning. Now when I see a > class with "final" that I want to subclass, I'm just going to rip the "final" > off, because chances are, I can do so safely. Now "final" does not serve as > a warning to me that I shouldn't do this. > > Sorry to focus on a superficial issue, but I think this really does matter > for usability. Hi Justin, Thanks for the comment! I understand both interpretations can be useful for different purposes, i.e. "don't inherit, it is not safe" vs "feel free to change this class without worrying with subclasses". I tend to think that the latter (which I believe is what Alexey has in mind) can, in general, be more useful in the sense that a class is usually safe to extend - you can always add features that are somewhat orthogonal to what the parent class is doing. I can, of course, imagine cases where your argument is valid - you can have an implementation that allocates memory based on the type of the parent therefore it does not observe the extra storage required by derived classes. However, I think these cases are less common. I also look at the programming guidelines and couldn't find a clear answer to the issue you raised. I don't have a strong opinion about this, just giving my two cents. Thanks again! Samuel http://reviews.llvm.org/D18172 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
