Re: [Vala] Final / Sealed classes in Vala

[Hans Vercammen <hveso3 gmail com>]

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