Studly caps

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Studly caps

Marco Pesenti Gritti
Hi,

the presence service is now using studly caps in package names and in
signal names. We should really have a convention about this...

There are a few of things I don't like that much about using studly caps
there:

- Using studly caps only for class names was giving some clue of what
was a class and what a package.
- The gtk/glib convention for signals is to use - instead and since we
are using those heavily we would have to mix styles.
- What should we do for single word package/signals? I guess they should
use caps too but... it's sort of ugly.

I don't have such a strong feeling about the specific convention... but
we should really make our conventions clear and use them consistently.

Marco
Reply | Threaded
Open this post in threaded view
|

Re: Studly caps

Marco Pesenti Gritti
Marco Pesenti Gritti wrote:

> Hi,
>
> the presence service is now using studly caps in package names and in
> signal names. We should really have a convention about this...
>
> There are a few of things I don't like that much about using studly
> caps there:
>
> - Using studly caps only for class names was giving some clue of what
> was a class and what a package.
> - The gtk/glib convention for signals is to use - instead and since we
> are using those heavily we would have to mix styles.
> - What should we do for single word package/signals? I guess they
> should use caps too but... it's sort of ugly.
>
> I don't have such a strong feeling about the specific convention...
> but we should really make our conventions clear and use them
> consistently.
The same for methods...

Marco
Reply | Threaded
Open this post in threaded view
|

Studly caps

Robert McQueen-2
In reply to this post by Marco Pesenti Gritti
Marco Pesenti Gritti wrote:
> Hi,
>
> the presence service is now using studly caps in package names and in
> signal names. We should really have a convention about this...

The convention on D-Bus is to use StudlyCaps (including Single words)
for methods, signals, interfaces names and object paths (except for the
parts which are derived from domain components). It's usually mapped by
the bindings to the convention of your local language, so in Glib:
 BarSignal -> BAR_SIGNAL (the constant) / bar-signal (the string)
 FooInterface.BazMethod -> foo_interface_baz_method

The point of this is that provided the D-Bus interfaces have a
consistent capitalisation, it's easy to map to the conventions of other
languages. If you try and put eg glib conventions into your D-Bus API,
it will come out as very ugly in other language bindings, so I'd
recommend against it.

> I don't have such a strong feeling about the specific convention... but
> we should really make our conventions clear and use them consistently.

In D-Bus, use the D-Bus conventions, which will map to the glib
conventions in those bindings, and the correct conventions elsewhere.

Regards,
Rob
Reply | Threaded
Open this post in threaded view
|

Studly caps

Marco Pesenti Gritti
Robert McQueen wrote:

> Marco Pesenti Gritti wrote:
>  
>> Hi,
>>
>> the presence service is now using studly caps in package names and in
>> signal names. We should really have a convention about this...
>>    
>
> The convention on D-Bus is to use StudlyCaps (including Single words)
> for methods, signals, interfaces names and object paths (except for the
> parts which are derived from domain components). It's usually mapped by
> the bindings to the convention of your local language, so in Glib:
>  BarSignal -> BAR_SIGNAL (the constant) / bar-signal (the string)
>  FooInterface.BazMethod -> foo_interface_baz_method
>
> The point of this is that provided the D-Bus interfaces have a
> consistent capitalisation, it's easy to map to the conventions of other
> languages. If you try and put eg glib conventions into your D-Bus API,
> it will come out as very ugly in other language bindings, so I'd
> recommend against it.
>
>  
>> I don't have such a strong feeling about the specific convention... but
>> we should really make our conventions clear and use them consistently.
>>    
>
> In D-Bus, use the D-Bus conventions, which will map to the glib
> conventions in those bindings, and the correct conventions elsewhere.
>
>  

D-Bus convention for the presence D-Bus service and glib conventions for
the tiny gobject based wrapper sounds like a sensible approach to me.

Marco

Reply | Threaded
Open this post in threaded view
|

Studly caps

Dan Williams-4
On Sat, 2006-07-22 at 02:36 +0200, Marco Pesenti Gritti wrote:

> Robert McQueen wrote:
> > Marco Pesenti Gritti wrote:
> >  
> >> Hi,
> >>
> >> the presence service is now using studly caps in package names and in
> >> signal names. We should really have a convention about this...
> >>    
> >
> > The convention on D-Bus is to use StudlyCaps (including Single words)
> > for methods, signals, interfaces names and object paths (except for the
> > parts which are derived from domain components). It's usually mapped by
> > the bindings to the convention of your local language, so in Glib:
> >  BarSignal -> BAR_SIGNAL (the constant) / bar-signal (the string)
> >  FooInterface.BazMethod -> foo_interface_baz_method
> >
> > The point of this is that provided the D-Bus interfaces have a
> > consistent capitalisation, it's easy to map to the conventions of other
> > languages. If you try and put eg glib conventions into your D-Bus API,
> > it will come out as very ugly in other language bindings, so I'd
> > recommend against it.
> >
> >  
> >> I don't have such a strong feeling about the specific convention... but
> >> we should really make our conventions clear and use them consistently.
> >>    
> >
> > In D-Bus, use the D-Bus conventions, which will map to the glib
> > conventions in those bindings, and the correct conventions elsewhere.
> >
> >  
>
> D-Bus convention for the presence D-Bus service and glib conventions for
> the tiny gobject based wrapper sounds like a sensible approach to me.

Ok; however I thought for consistency in the python PS bindings that I
should use StudlyCaps just to be the same as the underlying D-Bus API.
That can be trivially changed, however.  I don't really care.

Dan


Reply | Threaded
Open this post in threaded view
|

Studly caps

Marco Pesenti Gritti

> Ok; however I thought for consistency in the python PS bindings that I
> should use StudlyCaps just to be the same as the underlying D-Bus API.
> That can be trivially changed, however.  I don't really care.
>  

IHMO consistency in the higher level API is more important here. If you
think about it all the API people are going to use to build an
application for Sugar is GObject based. We might even want to rewrite
some of the python bits in C gobject at some point, to gain language
independency. Having it consistenly follow the gobject style would be nice.

Marco