On Fri, 2009-09-25 at 23:36 +1000, Magentus wrote: > On Wed, 23 Sep 2009 18:40:04 +0200, Didier 'Ptitjes' wrote: > > > For instance you may have an abstract class A that defines some > > methods as virtual, a child class B that re-implements some of the > > virtual methods of A and that wish the sub-classing to be blocked at > > its level, because subclasses would break its behavior by > > miss-overriding the virtuals. > > Something I don't get here... The whole point of subclassing, is to > make something old, do something new.
Yes, that is true. However, you would be surprised how often in oo land inheritance is misused in terms of 'is-a' and 'has-a', where composition should be preferred instead of inheritance. If a library developer can enforce that by marking the class final and ensuring it's behavior isn't changed by inheritance, why not allow that? > Isn't that like calling any developer that might be looking at > extending your class, an idiot? I'd have thought making sure virtuals > aren't miss-overridden, is the responsibility of proper documentation. That is a bit of harsh statement IMHO, but I think we could both agree it would avoid some RTFM statements :) > Does anyone have a concrete example of where this sort of thing is > actually appropriate, just for the sake of blocking sub-classing? I agree it is arguable and I don't see this as a high priority or must have feature. But in the end it comes down to language design and in vala's case, enforcing compile time errors instead of deferring critical errors and misbehavior at runtime. (just like abstract classes are not instantiatable, even if they don't contain abstract or pure virtual methods) Regards, Hans _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
