If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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.: