This weekend I’ve finally tried Vala, something I wanted to do for a while now. Vala is, for those of you that never tried it, like GOB, but on PCP and steroids and with a syntax that doesn’t make using it feel like you’re being skull-raped through your eye sockets. It’s, actually, quite a pleasant experience – if you ignore the utter brain damage of connecting signals by overloading the plus operator ((which is more a fault of C# than anything, and one of the reasons operator overloading should be banished using necromancy. Come on: signal = signal + handler
? Really?)).
Surely, there are a couple of issues with the underlying C translation layer:
- connecting signals passes the class instance pointer, but if your class does not have any property then an empty struct will be generated, which doesn’t create valid C code;
- if you then add a dummy int, the passed pointer is still called “self” but it’s never allocated, because the Vala compiler still expects for the class to inherit from GLib.Object in this case, while it really shouldn’t;
- so, if you want to connect to signals, you have to make your class inherit from Object, create an instance and connect to the signals in the constructor or inside a method;
The last point is a perfectly legitimate choice to be made by language designers: but, then, this snippet:
using GLib; using Gdict; class TestSource { void on_definition_found (Gdict.Context context, Gdict.Definition definition) { stdout.printf ("*definition for `%s' found:\n%s\n", definition.get_word(), definition.get_text()); } static void main (string[] args) { var loop = new GLib.MainLoop (null, false); var context = new Gdict.ClientContext ("dict.org", 2628); context.definition_found += on_definition_found; try { context.define_word ("*", "dictionary"); } catch (Glib.Error e) { warning (e.message); } loop.run (); } }
should fail to compile in Vala, and not in produce invalid C code ((I think this stems from the fact that Vala, like C#, allows a mixed OO-procedural approach, like Perl and Python; but those languages usually get it right)).
Anyway, Vala is an interesting project. If it had a better integration with the rest of the toolchain (gdb, valgrind, autotools, profilers, etc.) it should definitely become one of the first class citizens of GNOME ((for instance, Apple has native Objective-C support, and that is a layer above C like Vala)).
By the way, just to try out Vala I wrote the bindings for the Gdict API. They are mostly working, so if you want to check them out, you can clone the repository here:
git clone http://www.gnome.org/~ebassi/git/gdict-vala.git
Those are the bindings for the unstable version of Gdict, which will be released for GNOME 2.20.
The autotools support is under development right now:
http://bugzilla.gnome.org/show_bug.cgi?id=472048
As for the integration with gdb, there was some talk about that in the mailing list yesterday. Debugging is in the roadmap.
http://www.paldo.org/pipermail/vala/2007-September/thread.html#400
The support for classes not deriving from GObject is very new and we know that a lot of things are still missing there. I’d recommend to always derive your own classes from GObject unless there is a specific reason not to.
I agree that this snippet should fail to compile in Vala and that will also be the case in future versions, it just still misses quite some checks in the semantic analyzer. The idea in general is that it’s a vala bug whenever the generated C code fails to compile, unless you’re using invalid bindings.
> Come on: signal = signal + handler? Really?
The real story goes like this: signal_handler_list = signal_handler_list + handler
@fct: yep, I’ve seen the thread on the mailing list; good stuff, let’s hope it materialise soon – I can’t wait. :-)
@juerg: sure, that’s what I’ve learned anyway. and far from detracting your work, I think it’s a perfectly valid design decision to enforce OOP – it’s the template language (C#) that makes things harder. if you need a hand, I think I can work out a patch for the code generator.
@mathias: yeah, I know it’s treated implicitly like that, but what’s visible is “object.signal_name += handler” which is like adding apples to oranges and returning apples again. personally, I find this syntax flaky and a rape of the semantics of signal handling, but as I said above, it’s the template language’s fault, not Vala’s.