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 <b...@ucw.cz> _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list