IDL language

[Simon McVittie]

On Mon, 11 May 2009 at 09:59:56 -0400, David Zeuthen wrote:
> On Mon, 2009-05-11 at 14:36 +0100, Simon McVittie wrote:
> > > The D-Bus spec says to use CamelCase (actually it says WindowsStyleCaps)
> > > and the existing message bus and standard interfaces already use that
> > > naming convention. Would it be a big problem to just add an annotation
> > > for these corner case, say, 
> > > 
> > >  @NamingHint ("Send_DTMF")
> > >  SendDTMF (int32 stuff, ...)
> > 
> > That's fine for the bits where a convention exists (method names, signal names,
> > properties) - 
> 
> Interface names too.

To an extent, the interface name has two uses anyway - there's the part used
on D-Bus only, and the part used both on D-Bus and in the binding. For instance,
org_freedesktop_telepathy_connection_interface_aliasing_call_get_aliases() is
far too long

The hack we use in the Telepathy XML extensions is to set the <node> name
(which is otherwise meaningless in introspection XML used as a pseudo-IDL) to
"/Connection_Interface_Aliasing", as a hint to append that to the prefix in
the C code (in practice we get tp_cli_connection_interface_aliasing_... which
is still uncomfortably long, we should perhaps have used "conn" and "iface").

With hindsight, this should have been an attribute on the <interface> rather
than an abuse of the <node> name.

>  a) it seems bizarre to have different conventions for interfaces and
>     structs/enum and maybe a third convention for stuff we add later

What I was advocating was that this would be the convention for all new stuff,
since it contains all the information needed by any case convention I can
think of.

>  b) we can make the GLib code generator just fail if it's unable to
>     find a NamingHint and if there is no suitable way of inferring it
>     [1] and something like --infer-naming-hints were not given.

I'd prefer not to have --infer-naming-hints at all, if that argument means
"guess wildly in the presence of multiple capital letters".

> We can also make the proposed dbus-validate-typelib(1) tool actually
> error out (or warn) if there is no @NamingHint annotation for
> problematic names (e.g. those with two capitals following each other).

Requiring an explicit naming hint (in the IDL, or on the command line, or in
some helper file) for names with two consecutive capitals seems a reasonable
compromise if you want to use CamelCase throughout.

Because this IDL is new, I don't think it would be unreasonable to make this a
hard requirement in general - there's no installed base to be
backwards-compatible with, and you are still defining the language, so you
might as well define it in such a way that problematic usages are forbidden.

    Simon