IDL language

[David Zeuthen]

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.

> However, for the bits where D-Bus core has no convention because it doesn't
> have the concept at all (named structs, named enums, named flags, perhaps
> names for interfaces) it's not too late to establish a convention that doesn't
> have the same problems. 

It only has these problems for some runtimes (such as the GLib one) and 

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

 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.

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

    David

[1] : say, for a name SomeNormalName, the GLib code generator would
infer Some_Normal_Name.

For a name with two capitals following each other, e.g SendDTMF, the
GLib code generator would bail.

You'd fix that up via commandline arguments to the code generator or by
asking the upstream provider of the typelib to add the @NamingHint
annotation.