Re: [Vala] Class definitions

["Phil Housley" <undeconstructed gmail com>]

2008/6/2 Stephen Henry <stephenry gmail com>:
> Hi Guys,
>
> Your doing a really great job with Vala. I'm quite new to the
> technology, but there is one thing that I don't really like about it.
> I don't really understand why it is necessary to manually specify that
> classes derived from the Glib.GObject. To me, this just exposes too
> much information about the underlying implementation. I feel that Glib
> integration should be completely transparent to the user (well, as
> much as can be reasonably expected) and GObjects should be first class
> citizens in the language. I understand that there is the argument of
> needing to have a lightweight equivalent to "struct", without the
> overhead of GObject, but, isn't it the job of the compiler to
> automatically optimise this operation, not the user? Can't it be the
> case that all classes automatically inherit from GObject, but are then
> optimised during compilation (code generation?) depending whether they
> ever reference the GObject functionality?

There are a couple of things that make this difficult, but it all
really comes to down to the complexity of the existing systems/general
ecosystem.  There are at least three different types of things, that
are all basically classes, in general use, and you need to say exactly
which one you mean in order to interact with the outside world.

The SVN version of Vala has the following rules for classes, which I
think partially fulfills your suggestion:
 * A class declaration that doesn't derive at all from GObject is a
proper gtype registered type, with all the features of a class that
you would expect in a normal language (pretty much, it rather depends
what you are used to of course.)
 * A class derived at some level from GObject is a special case of the
above.  This sort of thing has properties and fancy construction.  If
you were writing an isolated application these extras might not be
needed, but lots of things in gnome rely things like being able to
instantiate classes programmatically with property lists - if you
don't derive from GObject you get a proper class, just not something
as powerful, and more importantly not as useful to outside users (for
bindings for example.)
 * Compact classes are not real gtypes, but do some class like things.
 In order to define one of these classes you have to specifically
annotation the declaration.  The main use of them currently is in
non-gobject bindings, but if you were writing a large Vala app, you
could probably find times when this is all the class you need.

So, Vala is moving to the default being a "proper" class, although not
a gobject one.  You'll get the glib/gtype stuff for free, but you'll
have to ask for the rest.

The reason this feels strange is that you get extra syntax depending
on the semantics of the program, but that's really the obvious way to
handle things.  In a lot of ways GObject is just another class that
you might or might not want to derive from, the unusual thing is that
it is so widely used and so relied on - for that reason it makes sense
to integrate its features very tightly in Vala.

> Anyway, keep up the good work. I really see this as being the key
> enabling technology to bringing GTK and GNOME platform to a wider
> audience.
>
> Stephen
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list

-- 
Phil Housley