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 <[EMAIL PROTECTED]> wrote:
>
> Em Sun, 14 Oct 2007 12:40:38 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
