Re: [Vala] Final / Sealed classes in Vala

[Jan Hudec <bulb ucw cz>]

On Sat, Sep 26, 2009 at 17:27:45 +0200, Didier 'Ptitjes' wrote:
> Michael B. Trausch wrote:
> > The idea of a sealed/final class can be used to mean a few things:
> > ...
>
> To follow Phil with use cases, Libgee would be in great need for
> final classes and methods.
>
> As an example, we would like that concrete collection
> implementations cannot be sub-classed. The public methods of these
> implementations all guarantee the respect of API contracts. Also
> those methods are for most overrides of virtual methods because the
> framework is made to be extensible and allow future enhancements
> (possibly by sub-classing).

Just like my earlier example with inheriting string, similar reasons apply to
inheriting concrete collection classes. For example a collection of options
would make perfect sense to be a collection plus special constructor or
initialization method to load it from a file and maybe a method to save it
back. Or a collection of headers would make perfect sense to be a collection
that does checks keys are valid identifiers on insertion.

Both these can *almost* be done by delegation, except
 - it's a lot more typing, so users will hate you for that, and
 - if some other interface expects the base class, you have to give it the
   delegee, but you loose any additional checking.

You can argue, that the second case should not happen, because any API should
take the interface, not the class, but all this is about user's who don't
know better, because those who do won't complain when they break things with
incorrect overriding.

So you can persuade me to agree it makes sense to declare, and ensure, that
particular virtual methods must not be overriden (carefuly -- my second
example involves overriding add!), but I don't buy the argument that the
class as a whole may not be inherited.

> There are Abstract* abstract classes available if one wants to start
> a new collection implementation.

I don't want to. I want to add some auxiliary functionality or additional
semantic checks to the otherwise completely standard collection
implementation.

> Also it is worth to note that enabling sub-classing on concrete
> implementations (like it is now) allows a possible failure because
> of the badly-design GObject construction. Thanks to Jakob Kroon to
> have pointed that to me.

The GObject system is somewhat strange and it is a little tricky to get the
usage right, but it is possible to implement the classes so they are
always constructed correctly.

And by the way, it has nothing to do with inheritance -- there are many other
cases where creating objects via GLib.Object.new is useful.

Note, that vala makes implementing classes correct w.r.t. GLib.Object.new
trickier because it sets construct properties and calls base constructor in
the construction method body instead of using dedicated syntax like C++ and
C# do.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>