4 ms·

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full bindings with zero maintenance overhead EXCEPT for fixing bugs in the generators or the initial work for adding a new language binding tool". At least the plan is to have language bindings "first class citizens" all coming out of core development (with yes, the core still in C - that's how we roll). Our cross-platform support hasn't been great and originally it was never intended/planned, but now we do port to Windows, Mac and Linux (X11 + Wayland), other Unixen... sure the ports need more work/maintenance and to be made easier and less prone to breaking, and we don't have iOS, android or Windows Phone ports (and no obscure OS's like Symbian, QNX etc.), so that's something to fix, but we're shifting design to push portability first and foremost and that allows for OS ports, so maybe this will pan out. There are Python bindings waiting int he wings that will come in once we're done with our interfaces work and the core OO layer is stable (not changing/breaking), so that language will get added. given the range of languages above and Python I think that means that adding more languages shouldn't be hard as most core concepts have been covered. Just FYI on "pick up favorite language and write cross-platform app".

daurnimator 10y ago
> LuaJIT bindings Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year (https://www.youtube.com/watch?v=J_hlbjj_9-Q https://www.youtube.com/watch?v=J_hlbjj_9-Q). From what I recall it was more of a full application framework rather than a library usable from existing processes. I did try to give them a go at some point, but could never get things working. Aside from this, the reliance on luajit makes this a no-go for me. (though perhaps you can use luaffi (https://github.com/facebook/luaffifb https://github.com/facebook/luaffifb) to alleviate this?)
- rasterman 10y ago
  well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?
  - daurnimator 10y ago
    > well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop. Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while
    - rasterman 10y ago
      node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.
      - daurnimator 10y ago
        You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway? Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results. I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/ http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?

daurnimator 10y ago

> LuaJIT bindings Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year (https://www.youtube.com/watch?v=J_hlbjj_9-Q https://www.youtube.com/watch?v=J_hlbjj_9-Q). From what I recall it was more of a full application framework rather than a library usable from existing processes. I did try to give them a go at some point, but could never get things working. Aside from this, the reliance on luajit makes this a no-go for me. (though perhaps you can use luaffi (https://github.com/facebook/luaffifb https://github.com/facebook/luaffifb) to alleviate this?)

rasterman 10y ago
well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?
- daurnimator 10y ago
  > well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop. Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while
  - rasterman 10y ago
    node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.
    - daurnimator 10y ago
      You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway? Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results. I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/ http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?