C++ bindings

[Havoc Pennington]

On Fri, 2003-11-07 at 09:08, Murray.Cumming@Comneon.com wrote:
> I'll definitely keep that in mind, but what I've seen so far suggests that
> there will be too many special cases. However, I have only explored a
> fraction of the API and I don't think I've fully understood everything yet.

I'm not saying autogen the bindings. I'm saying the way people would
_use_ the bindings may involve generating code, as it does for CORBA or
DCOP or the GLib bindings.

> I'm in no rush personally, but I'll try to put some crap in cvs so that
> others can look at it. Would you like me to put my crap in the freedesktop
> cvs or GNOME's?

It's up to you, if the bindings are generic C++ the freedesktop cvs
probably makes sense.

> > By code generation I mean either IDL -> sourcecode (CORBA model), or 
> > sourcecode -> IDL -> typelib (moc/DCOP model). Or IDL -> 
> > typelib perhaps, if you want to make people do more typing.
> 
> Thanks for the tip. I didn't realise that the glib bindings were generated.

They aren't, but the idea is that application code would (partially) be.
Specifically what the generator would create is a metadata blob in the
form of a static variable. You then #include this blob in your GObject
subclass implementation and it allows the glib bindings to type-safely
dynamically marshal methods on your object when dbus messages are
received.

This isn't implemented yet, though. It's the way the DCOP/Qt stuff
works.

There are some messages in the archives discussing this more IIRC.

> I'll be trying to wrap the lower level API as well as creating a higher
> level API like in the python bindings.

The lower level API is designed almost purely for the use of bindings; 
wrapping the main loop glue (DBusWatch, connection_set_watch_functions)
and the object data set/getters is probably pointless bloat/confusion in
your binding API.

Havoc