On Jan 11, 2008 1:25 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> I think I have shared my part in writing about the pro's and con's I
> see for the @Mount annotation, and all I got in return was "I don't
> like annotations".
>
> Why does it have to be a HUGE improvement? Annotations *ARE* Java! Not
> some foreign, alien construct: pure Java.
No, the point is here that you would have different ways to do the
same thing. Also, annotations are different from methods in classes.
> > than considering whether a plain Java alternative would be
> > appropriate. We should not make the same mistake with annotations.
>
> I don't buy the "annotations are replacements for XML configuration"
> argument. Just because we do something inside class methods doesn't
> mean it belongs there! We should not make the mistake to stay inside
> the method. Annotations are a first class citizen in Java and should
> be considered an equal alternative.
Then we disagree. Annotations have a very different purpose (meta
data) compared to regular methods and members.
> For instance the statelessness of a page. You specify that a page is
> stateless. You now have to override a method to provide that logic,
> but it is not logic... It is a configuration item that should be
> orthogonal to the page. I find it much clearer to see this specified
> in an annotation rather than some obscure overridden method 10 pages
> down:
>
> @Stateless
> public class MyPage extends WebPage {
> public MyPage() {
> }
> }
Yeah, I like @Stateless better too. But I don't like to have two
separate ways of doing the same thing.
> Don't get me wrong: I also don't want to spray arbitrary annotations
> around. Having 10 annotations before a page would make that rather
> illegible. However I am not going to ignore the usefulness of
> annotations because of "I don't like them" arguments. They have good
> uses, and I want to find those parts of our API that could better be
> implemented using annotations than by subclassing and overriding.
Well, then come with concrete use cases and argue for them. Let's
start putting those alternatives in a separate project, and later
argue whether they are useful enough to be put in the core project.
Eelco
