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.
