On Thu, 16 Feb 2017 20:36:21 +0100 "Dr. Michael Lauer" <mic...@vanille.de> said:
> Sorry for resurrecting such an old thread, but I just became aware of it. > > In case you didn’t know, me and some colleagues did quite a lot of work > on EFL bindings about 8 years ago. We came to a point where the bindings > were usable for some – small – apps, in particular integrating into the glib > main loop to get Vala’s async dbus communication working. > > By now I’m pretty sure the APIs have changed a lot, but perhaps some of this > work can be resurrected and used, if you’re interested about Vala. > > It remains to be discussed whether an automatic or semi-automatic > plus fine-tuned way of generating these bindings is to be preferred. > Back in the days, used a semi-automatic approach since I wanted the > bindings to feel as high-level-OO-like as possible. > > Would be cool to see some of this work being used. The machine were > git.freesmartphone.org <http://git.freesmartphone.org/> was hosted died some > time ago, but I just uploaded uploaded the repository from a backup to > https://github.com/freesmartphone/libeflvala/ > <https://github.com/freesmartphone/libeflvala/> we definitely want fully automatic bindings. no manual binding (beyond core/basic types). this is the path we already have for: js, lua, c++. there is a specific binding generator per language with just core data types (growable arrays, linked lists, stringshares etc.) hand-mapped because this tends to be specific per language target as most languages have a lot of these data types built in and so you want these to map cleanly. above this the base object class then also gets manually bound (ref counting, construction/destruction handling etc.). promises/futures are still a bit up in the air, but also manual due to languages often incorporating these into the core language itself. after this it's all automated. or should be. as we also GENERATE the C api from the .eo IDL files... but this is the new eo based api and not "legacy" which was done by hand over the years. so we are basically growing a whole new parallel api that embodies common design concepts in a high-level OO way in these .eo IDL files, then it's very easy to map efl api to almost any decent language automatically. i am NOT a fan of manual or even semi-automatic binding as it requires continual maintenance and eventually people get tired of doing it as it's generally boring painful work. get a generator + base bindings to work once and at most "fix the odd future bug in it", then have it automated. every time you do "make" in the efl tree then you get the bindings to tag along and update adding new classes, methods, types, events and so on automatically as it's all generated at build time. :) > Best regards, > > :M: > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
