[T5] Recommended naming of configurations

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

[T5] Recommended naming of configurations

Dan Adams
Let's say you have a service that allows multiple contributions. One of
the contributions is simply a list of other objects (say an ordered
configuration). What is the naming convention for the configuration
point for that list of objects? For instance, lets say you want to have
a list of FooBars contributed. Which of the following is recommended:

contributeFooBars()

contributeFooBarManager()

contributeMasterFooBar()

or would you recommend something else entirely? I think I like the first
one simply because it more readable in the modules that are
contributing.

--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

Howard Lewis Ship
Where I dropped the ball here, in a minor way, is that it should be
"contributeTo" as a prefix, or perhaps "configure".  It's a prefix on the
*service* being configured or contributed to.  So I would choose option #2
or #3.

I wonder if there's some value in something like:

@Contribute(FooBar.class)
public void whatWouldYouCallThis(Configuration<FooBarDatum> configuration) {
... }

This is heading a bit backwards from my initial goals, of naming conventions
over annotations, and raises the question of the convention for naming such
methods, but it would allow for more pleasing names such as
"contributeLoggingFilter" (with the annotation) vs.
"contributeRequestHandler" (which gives no indication what is being
contributed).


On 10/12/07, Dan Adams <[hidden email]> wrote:

>
> Let's say you have a service that allows multiple contributions. One of
> the contributions is simply a list of other objects (say an ordered
> configuration). What is the naming convention for the configuration
> point for that list of objects? For instance, lets say you want to have
> a list of FooBars contributed. Which of the following is recommended:
>
> contributeFooBars()
>
> contributeFooBarManager()
>
> contributeMasterFooBar()
>
> or would you recommend something else entirely? I think I like the first
> one simply because it more readable in the modules that are
> contributing.
>
> --
> Dan Adams
> Senior Software Engineer
> Interactive Factory
> 617.235.5857
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50

Creator Apache Tapestry and Apache HiveMind
Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

lasitha
Howard,

Just in case that was an invitation for proposals :), how about:
contributeSomethingToSomeService(), where 'Something' is optional?

Allows for a little more specificity while still being an easily
parsed convention.  And for those that don't care - its only two more
characters :)

In any case, +1 for not leaving it as is.

Cheers,
lasitha

Oh, p.s - immeasurable thanks for T5!

On 10/14/07, Howard Lewis Ship <[hidden email]> wrote:

> Where I dropped the ball here, in a minor way, is that it should be
> "contributeTo" as a prefix, or perhaps "configure".  It's a prefix on the
> *service* being configured or contributed to.  So I would choose option #2
> or #3.
>
> I wonder if there's some value in something like:
>
> @Contribute(FooBar.class)
> public void whatWouldYouCallThis(Configuration<FooBarDatum> configuration) {
> ... }
>
> This is heading a bit backwards from my initial goals, of naming conventions
> over annotations, and raises the question of the convention for naming such
> methods, but it would allow for more pleasing names such as
> "contributeLoggingFilter" (with the annotation) vs.
> "contributeRequestHandler" (which gives no indication what is being
> contributed).
>
>
> On 10/12/07, Dan Adams <[hidden email]> wrote:
> >
> > Let's say you have a service that allows multiple contributions. One of
> > the contributions is simply a list of other objects (say an ordered
> > configuration). What is the naming convention for the configuration
> > point for that list of objects? For instance, lets say you want to have
> > a list of FooBars contributed. Which of the following is recommended:
> >
> > contributeFooBars()
> >
> > contributeFooBarManager()
> >
> > contributeMasterFooBar()
> >
> > or would you recommend something else entirely? I think I like the first
> > one simply because it more readable in the modules that are
> > contributing.
> >
> > --
> > Dan Adams
> > Senior Software Engineer
> > Interactive Factory
> > 617.235.5857
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Partner and Senior Architect at Feature50
>
> Creator Apache Tapestry and Apache HiveMind
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

Nick Westgate
Tapestry-ioc already calls the "something" a configuration:
http://tapestry.apache.org/tapestry5/tapestry-ioc/configuration.html

so Howard's "configure" naming suggestion looks even better.
(This has been discussed previously in this list.)

Cheers,
Nick.


lasitha wrote:

> Howard,
>
> Just in case that was an invitation for proposals :), how about:
> contributeSomethingToSomeService(), where 'Something' is optional?
>
> Allows for a little more specificity while still being an easily
> parsed convention.  And for those that don't care - its only two more
> characters :)
>
> In any case, +1 for not leaving it as is.
>
> Cheers,
> lasitha
>
> Oh, p.s - immeasurable thanks for T5!
>
> On 10/14/07, Howard Lewis Ship <[hidden email]> wrote:
>> Where I dropped the ball here, in a minor way, is that it should be
>> "contributeTo" as a prefix, or perhaps "configure".  It's a prefix on the
>> *service* being configured or contributed to.  So I would choose option #2
>> or #3.
>>
>> I wonder if there's some value in something like:
>>
>> @Contribute(FooBar.class)
>> public void whatWouldYouCallThis(Configuration<FooBarDatum> configuration) {
>> ... }
>>
>> This is heading a bit backwards from my initial goals, of naming conventions
>> over annotations, and raises the question of the convention for naming such
>> methods, but it would allow for more pleasing names such as
>> "contributeLoggingFilter" (with the annotation) vs.
>> "contributeRequestHandler" (which gives no indication what is being
>> contributed).
>>
>>
>> On 10/12/07, Dan Adams <[hidden email]> wrote:
>>> Let's say you have a service that allows multiple contributions. One of
>>> the contributions is simply a list of other objects (say an ordered
>>> configuration). What is the naming convention for the configuration
>>> point for that list of objects? For instance, lets say you want to have
>>> a list of FooBars contributed. Which of the following is recommended:
>>>
>>> contributeFooBars()
>>>
>>> contributeFooBarManager()
>>>
>>> contributeMasterFooBar()
>>>
>>> or would you recommend something else entirely? I think I like the first
>>> one simply because it more readable in the modules that are
>>> contributing.
>>>
>>> --
>>> Dan Adams
>>> Senior Software Engineer
>>> Interactive Factory
>>> 617.235.5857
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Howard M. Lewis Ship
>> Partner and Senior Architect at Feature50
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

lasitha
Thanks Nick - you're right, i should have looked over list and jira first:
http://thread.gmane.org/gmane.comp.java.tapestry.user/51015
https://issues.apache.org/jira/browse/TAPESTRY-1679

I agree that 'configure' is a step forward -
configureRequestHandler() is better than contributeRequestHandler().

I think i see what you mean by tapestry-ioc calling 'something' a
configuration - the arguments to contributor methods are of type
Configuration, OrderedConfiguration or MappedConfiguration.  Is that
what you mean?

What i heard Howard saying is that it might be helpful to allow the
contributor method name itself to describe what is being contributed,
hence my suggestion of, eg:
contributeTimingFilterToRequestHandler().

This is particularly helpful when i have a single, specific
contribution to make.  For cases where i can make multiple
contributions from within a single method, or the specificity is
unnecessary, i could fall back on just:
contributeToRequestHandler().

I apoligize if i'm rehashing an old discussion - the threads i found
hadn't spawned much discussion, but i could just have missed the
interesting ones.

Also, a quick question about protocol: once an issue has been logged
on jira, do y'all prefer to move discussions there?  I'm (a few
months) new to the community so would appreciate direction.

Thanks,
lasitha.

On 10/15/07, Nick Westgate <[hidden email]> wrote:

> Tapestry-ioc already calls the "something" a configuration:
> http://tapestry.apache.org/tapestry5/tapestry-ioc/configuration.html
>
> so Howard's "configure" naming suggestion looks even better.
> (This has been discussed previously in this list.)
>
> Cheers,
> Nick.
>
>
> lasitha wrote:
> > Howard,
> >
> > Just in case that was an invitation for proposals :), how about:
> > contributeSomethingToSomeService(), where 'Something' is optional?
> >
> > Allows for a little more specificity while still being an easily
> > parsed convention.  And for those that don't care - its only two more
> > characters :)
> >
> > In any case, +1 for not leaving it as is.
> >
> > Cheers,
> > lasitha
> >
> > Oh, p.s - immeasurable thanks for T5!
> >
> > On 10/14/07, Howard Lewis Ship <[hidden email]> wrote:
> >> Where I dropped the ball here, in a minor way, is that it should be
> >> "contributeTo" as a prefix, or perhaps "configure".  It's a prefix on the
> >> *service* being configured or contributed to.  So I would choose option #2
> >> or #3.
> >>
> >> I wonder if there's some value in something like:
> >>
> >> @Contribute(FooBar.class)
> >> public void whatWouldYouCallThis(Configuration<FooBarDatum> configuration) {
> >> ... }
> >>
> >> This is heading a bit backwards from my initial goals, of naming conventions
> >> over annotations, and raises the question of the convention for naming such
> >> methods, but it would allow for more pleasing names such as
> >> "contributeLoggingFilter" (with the annotation) vs.
> >> "contributeRequestHandler" (which gives no indication what is being
> >> contributed).
> >>
> >>
> >> On 10/12/07, Dan Adams <[hidden email]> wrote:
> >>> Let's say you have a service that allows multiple contributions. One of
> >>> the contributions is simply a list of other objects (say an ordered
> >>> configuration). What is the naming convention for the configuration
> >>> point for that list of objects? For instance, lets say you want to have
> >>> a list of FooBars contributed. Which of the following is recommended:
> >>>
> >>> contributeFooBars()
> >>>
> >>> contributeFooBarManager()
> >>>
> >>> contributeMasterFooBar()
> >>>
> >>> or would you recommend something else entirely? I think I like the first
> >>> one simply because it more readable in the modules that are
> >>> contributing.
> >>>
> >>> --
> >>> Dan Adams
> >>> Senior Software Engineer
> >>> Interactive Factory
> >>> 617.235.5857
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> --
> >> Howard M. Lewis Ship
> >> Partner and Senior Architect at Feature50
> >>
> >> Creator Apache Tapestry and Apache HiveMind
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

com.liigo@gmail.com
In reply to this post by Howard Lewis Ship
在 Sun, 14 Oct 2007 23:40:38 +0800,Howard Lewis Ship <[hidden email]> 写
道:

> Where I dropped the ball here, in a minor way, is that it should be
> "contributeTo" as a prefix, or perhaps "configure".  It's a prefix on the
> *service* being configured or contributed to.  So I would choose option  
> #2
> or #3.
>
> I wonder if there's some value in something like:
>
> @Contribute(FooBar.class)
> public void whatWouldYouCallThis(Configuration<FooBarDatum>  
> configuration) {
> ... }
>
> This is heading a bit backwards from my initial goals, of naming  
> conventions
> over annotations, and raises the question of the convention for naming  
> such
> methods, but it would allow for more pleasing names such as
> "contributeLoggingFilter" (with the annotation) vs.
> "contributeRequestHandler" (which gives no indication what is being
> contributed).
>

I like "contributeTo", and like @Contribute too.

>
> On 10/12/07, Dan Adams <[hidden email]> wrote:
>>
>> Let's say you have a service that allows multiple contributions. One of
>> the contributions is simply a list of other objects (say an ordered
>> configuration). What is the naming convention for the configuration
>> point for that list of objects? For instance, lets say you want to have
>> a list of FooBars contributed. Which of the following is recommended:
>>
>> contributeFooBars()
>>
>> contributeFooBarManager()
>>
>> contributeMasterFooBar()
>>
>> or would you recommend something else entirely? I think I like the first
>> one simply because it more readable in the modules that are
>> contributing.
>>
>> --
>> Dan Adams
>> Senior Software Engineer
>> Interactive Factory
>> 617.235.5857
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

Thiago H de Paula Figueiredo
In reply to this post by Howard Lewis Ship
Em Sun, 14 Oct 2007 12:40:38 -0300, Howard Lewis Ship <[hidden email]>  
escreveu:

> This is heading a bit backwards from my initial goals, of naming  
> conventions over annotations, and raises the question of the convention  
> for naming such methods,

I think that to rely just on naming conventions has a serious  
disadvantage: one typo and the method is not invoked when it should.

Your example with annotations, copied below, has the con of letting the  
developer choose some bad method name. On the other hand, it's almost  
impossible get the contribution wrong: the compiler checks if FooBar is an  
existing class, something that wouldn't happen using just naming  
conventions.

> @Contribute(FooBar.class)
> public void whatWouldYouCallThis(Configuration<FooBarDatum>  
> configuration) {

Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Recommended naming of configurations

Davor Hrg
I'm with thiago here,

module is not something we change all the time
like pages and components, it gets written bit by bit.
Naming conventions here don't speed-up development in scope
of the whole project.

@Contribute(FooBar.class)

I would even say it's faster because you can use autocomplete.
You can search for references to your class and see all modules
that contribute to your Service. You can use F3 in eclipse (or sth else in
other IDE)
to go the the code of the FooBar.class.

even with sth like this:

@Contribute(FooBar.class)
uglyMethodName(){....}

it is clear that we are contributing to FooBar.

service-ids are removed in 5.0.6 .... I belive @Contribute
would be more in-line with it.


If module is dependant on the module that is not present,
ClassDefNotFound exception will be thrown at some point,
which can be caught and contribution ignored (with proper warning in the
log)

Davor Hrg



On 10/18/07, Thiago H. de Paula Figueiredo <[hidden email]> wrote:

>
> Em Sun, 14 Oct 2007 12:40:38 -0300, Howard Lewis Ship <[hidden email]>
> escreveu:
>
> > This is heading a bit backwards from my initial goals, of naming
> > conventions over annotations, and raises the question of the convention
> > for naming such methods,
>
> I think that to rely just on naming conventions has a serious
> disadvantage: one typo and the method is not invoked when it should.
>
> Your example with annotations, copied below, has the con of letting the
> developer choose some bad method name. On the other hand, it's almost
> impossible get the contribution wrong: the compiler checks if FooBar is an
> existing class, something that wouldn't happen using just naming
> conventions.
>
> > @Contribute(FooBar.class)
> > public void whatWouldYouCallThis(Configuration<FooBarDatum>
> > configuration) {
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>