IDL language

[Simon McVittie]

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
>   done.

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.

    Simon