Re: [Vala] Final / Sealed classes in Vala

[Didier 'Ptitjes' <ptitjes free fr>]

Jan Hudec wrote:
> On Tue, Sep 22, 2009 at 06:40:10 +0200, Marco Trevisan (Treviño) wrote:
> > Is it possible to define both in VAPIs and in a vala code a class which
> > can not be extended?
> >
> > I mean something like "final" does for Java and "sealed" for C#...
>
> I don't think so. Though some classes are not inheritable because they lack
> proper construction functions. That's (unfortunately) the case for most
> classes in the GLib namespace.
>
> And I think vala should *NOT* get 'sealed'. It does not need it. In fact, C#
> does not need it either -- they added it because Java had 'final', but in
> Java it partly replaces missing non-virtual methods. In C# it's mostly
> annoying.

I must disagree on this. There are use cases for 'sealed' or 'final' (or
whatever you name it).

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.

> That's only useful in Java which does not have non-member methods. And even
> there the final keyword is useless -- it's static, so it cannot be virtual
> and if you call it as Utility.my_method(), you always call that method and
> nothing else. Only instance methods may be overriden.
>
> In vala, you just use namespace as:
>
> namespace Utility {
>     public void my_method();
> }

I there is a mix here between two issues:
- static function sets (where namespaces could apply but this is only 
one point of view)
- the need to seal some classes to avoid sub-classing

I think the problem to not have it in Vala is more a technical problem 
where nothing will avoid C users (in the current GObject) to subclass 
the classes that would be marked as sealed in Vala.

Best regards, Didier.