Dub and GtkD

[Artur Skawina]

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.