simon.mcvittie at collabora.co.uk
Tue May 12 06:08:42 PDT 2009
On Mon, 11 May 2009 at 12:47:09 -0400, David Zeuthen wrote:
> Btw, my view is that in an ideal world, generated code shouldn't
> be public API. Users (which would be applications, not libraries)
> would just generate D-Bus bindings part of their internal API.
> E.g. to use Telepathy or DeviceKit-disks, I'd just suck in the
> typelibs and generate code directly in my application and then I'm
This effectively gives the code generator and the typelib the status of a
static library, which we all know has disadvantages. We've had bugs in the
telepathy-glib code generator before; the fact that most of the generated code
lives in telepathy-glib means we can fix most of them transparently.
> Of course this view isn't really tenable in the real world insofar
> that it's often desirable to have local code running in the client.
> For example, in Telepathy you need that to update your chatroom
> property (an array of chatroom participants) because you want avoid
> PropertyChanged on that sucker so you'd need code handling custom
> signals to convey what could have been a PropertyChanged signal.
> So it makes sense to extend the generated code to handle that and
> offer that as library API to Telepathy users. So the library API
> would include some generated code (that you extended as well).
Right, I think a high-quality binding for a complex API will in practice
have to have hand-written code that wraps or extends the generic API, at least
for some interfaces (in telepathy-glib we wrap most of the core Channel,
Connection etc. interfaces but use generated code for various optional
interfaces; in telepathy-qt4 we have more hand-written code).
> But keep in mind that people will use lots of other tools for generating
> typelibs (gobject-introspection, Java, hand-write them, whatever) so in
> general it's hard to guarantee that you have a @NamingHint annotation
> for a problematic name.
At the risk of repeating myself: you are designing the IDL, now, so what is
valid or invalid IDL is your choice. If you want the definition of the IDL to
include "problematic names MUST have a NamingHint" (which I would advocate)
then now is the time to say that (I assume there's a description of the IDL
other than "what this tool parses"?), and it'll be other-tool users' problem if
their other-tool generates (something that you'll define as) invalid IDL.
More information about the dbus