On 12/23/13 19:30, Mike Wey wrote: > On 12/22/2013 10:00 PM, Artur Skawina wrote: >> On 12/22/13 20:21, Mike Wey wrote: >>> On 12/22/2013 03:36 PM, Russel Winder wrote: >>>> >>>> Python now uses the reflection approach to providing a Python binding to >>>> the API: PyGTK has given way to PyGobject. Has the PyGobject approach >>>> been rejected for GtkD staying with the PyGtk approach? >>> >>> I don't think that would be a good approach with D, you either need a whole >>> lot of compile time magic, or loose type safety and do everything at >>> runtime. >> >> It's not that bad; no compile time magic and zero runtime overhead is >> possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 >> >> While I haven't updated those bindings in ~ two years, they should >> still work; may just need some tweaks, to deal with recent d language >> changes and to support newer lib features. The biggest remaining issue >> is lack of integrated Cairo bindings. > > Those are generated from the gir files beforehand like GtkD is generated from > the documentation (Moving to a gir based generator is on the TODO list, but > time currently doesn't permit it). While with the PyGobject approach the > bindings aren't generated beforehand but everything is done at runtime.
Didn't realize that. It kind of makes sense for a scripting language which does not care about performance at all[1]. It doesn't for a compiled language like D, where the equivalent would be to extract the gi/typelib data at /compile-time/. Which could be done via CTFE and mixins. But, as the lib i/f is very stable, it's much better to pay the conversion cost once and use a cached, pre-built version. The only advantage of parsing the introspection data at run-time would be that you could use a compiled D binary to access libs that it didn't know about at build time. Writing programs that use dlls w/o having any idea about the interface that those libs provide isn't exactly common. All checks would have to be done at runtime, which is what "loose type safety" meant, i guess. It didn't occur to me that somebody might want this functionality in a compiled statically typed language. Something that /was/ on my to-do list is a binary gtk-server like approach, that would allow decoupling the gui parts from the "core" application. In D this could be done transparently, with full type safety and negligible runtime cost (might still be cheaper than using gtkd). artur [1] If it did, it could just build (and cache) a bindings-dll on first use, avoiding ffi etc. Probably only matters in practice if you're already JITting the code anyway, as dealing with the args will be expensive.