Enlightenment Introduces Eolian, EFL C Generator

[phoronix]

Phoronix: Enlightenment Introduces Eolian, EFL C Generator

The newest component to the Enlightenment Foundation Libraries (EFL) is Eolian, an EO object parser and C code generator...

http://www.phoronix.com/vr.php?view=MTYyMDA

[Ancurio]

This very much sounds like the entire GTK+ -> GObject process all over again..

[liam]

This very much sounds like the entire GTK+ -> GObject process all over again..

I had the same thought. Considering that this is rasterman I'd bet this is considerably lighter weight.
Slightly curious about the format of the eolian metadata files...

[Ancurio]

I have to day though that the "multiple inheritance" part is a bit intriguing, as that feature was intentionally left out of GObject (interfaces don't count).

[raster]

This very much sounds like the entire GTK+ -> GObject process all over again..

in some ways it is just like that. i even looked at gobject with the view of using it, but it wasn't right for us. eo has several things different. it's more geared towards our needs and our existing objects we already had buried higher up the stack (this just moves it down the stack and unifies it). one of the big things that is different is the eoid mapping. for compatibility objects still come out as a Eo * (a pointer), but it's no longer actually a pointer to memory you can dereference. it's really a table ID stuffed into a pointer with generation counts (generation counts is something windows uses for GUIDs and that is actually a good idea, and this averts many false positives). it means that you don't direct-access an object by address, but via indirection making your code far safer at runtime to "oopses" (kept an object ptr/ref/id around then used it long after deletion - yes we do refcounting too, but let's say you forgot). this indirection of course costs, so to mitigate that, we can batch calls to share a single table deref across multiple method calls. e.g.:


eo_do(obj,
gui_move(x, y),
gui_resize(width, height),
color_set(r, g, b, a),
visible_set(1));


this is rather common - to actually set multiple properties or call multiple methods in a batch-like situation. this means we can share the table deref across 3, 4, 5 or more calls in a row.

[raster]

I have to day though that the "multiple inheritance" part is a bit intriguing, as that feature was intentionally left out of GObject (interfaces don't count).

it was an explicit requirement to do multiple inheritance, so it's there. we have multiple inheritance already implicit in our api's but have had to duplicate stuff all over. this should improve that.