You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2014/10/18 02:11:18 UTC

[dispatch] VOTE: Consistent naming convention for management attributes.

While working on https://issues.apache.org/jira/browse/DISPATCH-56 I
have noticed that dispatch currently uses 3 different conventions for
naming management attributes:

- foo_bar
- foo-bar
- fooBar

Please vote for your favorite. 

My vote is foo_bar. It's a legal identifier in most programming
languages and I have an irrational hatred of fooBar.
However note fooBar is the convention used by the AMQP management spec
(sigh) and we have already written the code to cope with foo-bar.

Cheers,
Alan.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Re: [dispatch] VOTE: Consistent naming convention for management attributes.

Posted by Justin Ross <jr...@apache.org>.
On Mon, Oct 20, 2014 at 9:39 AM, Alan Conway <ac...@redhat.com> wrote:

>
> ----- Original Message -----
> > So I'm speaking with my AMQP management / consistency across the entire
> > Qpid project hats on, rather than to Dispatch specifically.
> >
> > Hyphens are not valid in property names in JMS and so should be avoided
> (as
> > though I'm sure Robbie is working on a way to encode them within a legal
> > name, it's going to be kludgy).
> >
> > From a consistency point of view, Alan has already mentioned that all the
> > AMQP standard attributes are in (lower) camel case.  All the attributes
> on
> > objects managed through the Java Broker are similarly in lower camel.
> > Therefore I would think that that would be the least surprising.
> Obviously
> > irrational hate is a powerful counter argument however :-).
>
> I hate to admit it but the C++ broker's management attributes are also
> lowerCamelCase. I think this is a stronger argument than personal hatred,
> no matter how irrational.
>
> I tearfully switch my vote to nastyUglyCamelCase.
>
> Justin what do you think?


Yeah, I agree.  +1 to ughStudlyCaps, ;).

Re: [dispatch] VOTE: Consistent naming convention for management attributes.

Posted by Alan Conway <ac...@redhat.com>.
----- Original Message -----
> So I'm speaking with my AMQP management / consistency across the entire
> Qpid project hats on, rather than to Dispatch specifically.
> 
> Hyphens are not valid in property names in JMS and so should be avoided (as
> though I'm sure Robbie is working on a way to encode them within a legal
> name, it's going to be kludgy).
> 
> From a consistency point of view, Alan has already mentioned that all the
> AMQP standard attributes are in (lower) camel case.  All the attributes on
> objects managed through the Java Broker are similarly in lower camel.
> Therefore I would think that that would be the least surprising. Obviously
> irrational hate is a powerful counter argument however :-).

I hate to admit it but the C++ broker's management attributes are also lowerCamelCase. I think this is a stronger argument than personal hatred, no matter how irrational.

I tearfully switch my vote to nastyUglyCamelCase.

Justin what do you think?

Cheers,
Alan.

> 
> -- Rob
> 
> On 18 October 2014 04:39, Justin Ross <jr...@apache.org> wrote:
> 
> > I'm good with underscores. Truth be told, I have a mild preference for the
> > hyphens and think translation to legal identifiers is trivial, but I can
> > tell I'm gonna lose that one.
> >
> > I share your visceral distaste for camelCase. We should form a club.
> >
> > +1 to underscores, and +manymany to not having three different conventions
> > in one component.
> >
> > Justin
> > On Oct 17, 2014 8:11 PM, "Alan Conway" <ac...@redhat.com> wrote:
> >
> > > While working on https://issues.apache.org/jira/browse/DISPATCH-56 I
> > > have noticed that dispatch currently uses 3 different conventions for
> > > naming management attributes:
> > >
> > > - foo_bar
> > > - foo-bar
> > > - fooBar
> > >
> > > Please vote for your favorite.
> > >
> > > My vote is foo_bar. It's a legal identifier in most programming
> > > languages and I have an irrational hatred of fooBar.
> > > However note fooBar is the convention used by the AMQP management spec
> > > (sigh) and we have already written the code to cope with foo-bar.
> > >
> > > Cheers,
> > > Alan.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: dev-help@qpid.apache.org
> > >
> > >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Re: [dispatch] VOTE: Consistent naming convention for management attributes.

Posted by Rob Godfrey <ro...@gmail.com>.
So I'm speaking with my AMQP management / consistency across the entire
Qpid project hats on, rather than to Dispatch specifically.

Hyphens are not valid in property names in JMS and so should be avoided (as
though I'm sure Robbie is working on a way to encode them within a legal
name, it's going to be kludgy).

>From a consistency point of view, Alan has already mentioned that all the
AMQP standard attributes are in (lower) camel case.  All the attributes on
objects managed through the Java Broker are similarly in lower camel.
Therefore I would think that that would be the least surprising. Obviously
irrational hate is a powerful counter argument however :-).

-- Rob

On 18 October 2014 04:39, Justin Ross <jr...@apache.org> wrote:

> I'm good with underscores. Truth be told, I have a mild preference for the
> hyphens and think translation to legal identifiers is trivial, but I can
> tell I'm gonna lose that one.
>
> I share your visceral distaste for camelCase. We should form a club.
>
> +1 to underscores, and +manymany to not having three different conventions
> in one component.
>
> Justin
> On Oct 17, 2014 8:11 PM, "Alan Conway" <ac...@redhat.com> wrote:
>
> > While working on https://issues.apache.org/jira/browse/DISPATCH-56 I
> > have noticed that dispatch currently uses 3 different conventions for
> > naming management attributes:
> >
> > - foo_bar
> > - foo-bar
> > - fooBar
> >
> > Please vote for your favorite.
> >
> > My vote is foo_bar. It's a legal identifier in most programming
> > languages and I have an irrational hatred of fooBar.
> > However note fooBar is the convention used by the AMQP management spec
> > (sigh) and we have already written the code to cope with foo-bar.
> >
> > Cheers,
> > Alan.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>

Re: [dispatch] VOTE: Consistent naming convention for management attributes.

Posted by Justin Ross <jr...@apache.org>.
I'm good with underscores. Truth be told, I have a mild preference for the
hyphens and think translation to legal identifiers is trivial, but I can
tell I'm gonna lose that one.

I share your visceral distaste for camelCase. We should form a club.

+1 to underscores, and +manymany to not having three different conventions
in one component.

Justin
On Oct 17, 2014 8:11 PM, "Alan Conway" <ac...@redhat.com> wrote:

> While working on https://issues.apache.org/jira/browse/DISPATCH-56 I
> have noticed that dispatch currently uses 3 different conventions for
> naming management attributes:
>
> - foo_bar
> - foo-bar
> - fooBar
>
> Please vote for your favorite.
>
> My vote is foo_bar. It's a legal identifier in most programming
> languages and I have an irrational hatred of fooBar.
> However note fooBar is the convention used by the AMQP management spec
> (sigh) and we have already written the code to cope with foo-bar.
>
> Cheers,
> Alan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>