Sha256: e392fec5e7710de0357dc4a2c6fca1a490b80082ec6bbcdd7503aca3100e1c01

Contents?: true

Size: 1.5 KB

Versions: 3

Compression:

Stored size: 1.5 KB

Contents

= TODO

== Use GIR to bootstrap the GIRepository namespace

Currently, all the classes used to read the GIR are hand-coded. It should
be possible to hand-code only part of it and use that to generate the rest.
This would also integrate that properly with the rest of the GObject type
system.

Update: This has been tried, but the problem is that the GIRepository
namespace is not object-oriented: The Info structs are not GObjects, and
the methods that act upon them are just functions in the GIRepository
namespace. Perhaps some custom method_missing can be implemented to handle
this, though.

== Handle passing of generic pointers

Many GObject methods take a pointer to 'user data'. This means we should be
able to pass any Ruby object. On the other hand, these cases cannot be
distinguished, based on the GIR data, from methods that take a pointer to
any GObject.

I'm currently leaning towards passing the object id as the value of the
'gpointer'. Special overrided will have to be used for the cases where the
'gpointer' actually needs to be a GObject. I consider it an omission in
GIRepository that these two cases are not distinguished.

== Compatibility with all implementations.

Currently, there are the following incompatibilities:

* The MRI implementation does not allow invoking layout more than once. In
  particular, this means you cannot subclass a struct and change (augment)
  the layout. This *not* a problem in JRuby.

* JRuby disables ObjectSpace by default, so using _id2ref is not ideal.

== See Also

rake notes

Version data entries

3 entries across 3 versions & 1 rubygems

Version Path
gir_ffi-0.0.3 TODO.rdoc
gir_ffi-0.0.2 TODO.rdoc
gir_ffi-0.0.1 TODO.rdoc