Maybe the implementation of this idea that I'm looking at is bad.
The problem is the annotation doesn't give you an idea of what the
method should support to receive the event object. It is done in a way
that works with no parameters in the method, or any parameters in the
method.
That is
@PlayTrumpet
public void annotatedListen(Event ev) {
}
Works (and you get the "event")
@PlayTrumpet
public void annotatedListen() {
}
Works, and obviously you get no event
@PlayTrumpet
public void annotatedListen(String trumpet) {
}
Works, and you don't get the event
@PlayTrumpet
public void annotatedListen(String trumpet, Event event) {
}
I have no idea what it does!!!!
This is almost annotation abuse because you don't clearly know what
the contract is to get the event, which I think is bad API design.
(Oh and not annotating the class as a @Listener ... results in your
listener not working, that's another pain point)
On Oct 26, 10:51 pm, Cédric Beust ♔ <[email protected]> wrote:
> > Horrible!
>
> I disagree.
>
> I started thinking in that direction not long ago and I went in more details
> about these ideas in this post called "Local message
> bus"<http://beust.com/weblog/2010/07/26/local-message-bus/>
> .
>
> I think this approach has merit and like you say, it saves tons of code by
> avoiding the proliferation of PropertyChangeSupport objects everywhere and
> also by not forcing listeners to implement interfaces while they only care
> about one or two methods. It also decouples objects from observers radically
> to the point of having n+m connections instead of n*m (at the cost of having
> all these objects depend on the same local bus).
>
> Overall, I haven't found this compelling enough to start exposing it in
> TestNG but I'm not far from making the jump.
>
> --
> Cédric
>
> On Tue, Oct 26, 2010 at 4:36 PM, Augusto Sellhorn <
>
>
>
>
>
>
>
>
>
> [email protected]> wrote:
> > Annotations are a funny thing, you can (like anything) also abuse
> > them. There's a project out there (don't know if I should point it
> > out) that decided to create listeners via annotations instead of
> > listener interfaces.
>
> > It actually ends up with the code being less clear than the
> > alternative.
>
> > ex:
>
> > public class TrumpetTest implements TrumpetListener{
> > public void playTrumpet(Event ev) {
> > }
>
> > public Test() {
> > Trumpet trumpet = new Trumpet ();
> > trumpet .addTrumpetListener(this);
> > }
> > }
>
> > vs
>
> > @Listener
> > public class TrumpetTest {
> > @PlayTrumpet
> > public void annotatedListen(Event ev) {
> > }
>
> > public Test() {
> > Trumpet trumpet = new Trumpet ();
> > trumpet .addListener(this);
> > }
> > }
>
> > Now the annotation approach makes it so that there are less
> > addXXXListener() methods, and I can have an uber listener that has a
> > list of annotations (@PlayTrumpet, @FixTrumpet, etc) but this makes
> > the code harder to maintain.
>
> > The annotation makes it so there's only one method signature for the
> > events, with a shared event object and also (at least in the API I'm
> > talking about) you can tag a method with an annotation with different
> > args, you just don't get the event (or even know about the contract
> > for the event).
>
> > Horrible!
>
> > On Oct 25, 6:41 pm, Liam Knox <[email protected]> wrote:
> > > Yes fantastic metric characters are in measuring bolierplate
>
> > > i.e
>
> > > foo() {
> > > t.s();
>
> > > t.c();
>
> > > }
>
> > > or
>
> > > @Transactional
> > > foo(){}
>
> > > On Mon, Oct 25, 2010 at 10:31 PM, Kevin Wright <[email protected]
> > >wrote:
>
> > > > No, because that's based on an assumption that more lines = more
> > > > functionality
>
> > > > Though I can see how those in favour of not removing boilerplate, and
> > > > questioning the benefits of a 30% reduction might see this as a good
> > metric
>
> > > > On 25 October 2010 14:28, Liam Knox <[email protected]> wrote:
>
> > > >> Should we go back to measuring productivity by lines of code written?
>
> > > >> On Mon, Oct 25, 2010 at 10:26 PM, Augusto Sellhorn <
> > > >> [email protected]> wrote:
>
> > > >>> This is really bizarre, I've heard people say that fewer lines of
> > code
> > > >>> is desirable, but this is the first time I hear somebody say that X%
> > > >>> fewer characters lead almost exactly to X% reduction in complexity!
>
> > > >>> ---------------
>
> > > >>> for(int
> > > >>> indexOfAuthorInCurrentIteration=0;
> > > >>> indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length;
> > > >>> ++indexOfAuthorInCurrentIteration) {
> > > >>> Author currentAuthorBeingIteratedOver
> > > >>> = authorsFromNameQuery[indexOfAuthorInCurrentIteration]
> > > >>> // do something with the author
> > > >>> }
>
> > > >>> ---------------
>
> > > >>> Nobody is saying you have to use super long names here, what you are
> > > >>> saying is that less characters more % reduction in complexity, which
> > > >>> leads to this
>
> > > >>> for (int i=0; i <= aq.length; ++i) {
> > > >>> Author aa = aq[i];
> > > >>> // do something with the author
> > > >>> }
>
> > > >>> Which I don't think results in any % less chances of bugs, as a
> > matter
> > > >>> of fact it ends up being less readable than some reasonable and clear
> > > >>> names that could have been applied.
>
> > > >>> I hope in your code reviews you are not doing character counts and
> > > >>> blasting developers on these bogus measurements.
>
> > > >>> --
> > > >>> You received this message because you are subscribed to the Google
> > Groups
> > > >>> "The Java Posse" group.
> > > >>> To post to this group, send email to [email protected].
> > > >>> To unsubscribe from this group, send email to
> > > >>> [email protected]<javaposse%2bunsubscr...@googlegroups
> > > >>> .com>
> > <javaposse%2bunsubscr...@googlegroups .com>
> > > >>> .
> > > >>> For more options, visit this group at
> > > >>>http://groups.google.com/group/javaposse?hl=en.
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > Groups
> > > >> "The Java Posse" group.
> > > >> To post to this group, send email to [email protected].
> > > >> To unsubscribe from this group, send email to
> > > >> [email protected]<javaposse%2bunsubscr...@googlegroups
> > > >> .com>
> > <javaposse%2bunsubscr...@googlegroups .com>
> > > >> .
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/javaposse?hl=en.
>
> > > > --
> > > > Kevin Wright
>
> > > > mail / gtalk / msn : [email protected]
> > > > pulse / skype: kev.lee.wright
> > > > twitter: @thecoda
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "The Java Posse" group.
> > > > To post to this group, send email to [email protected].
> > > > To unsubscribe from this group, send email to
> > > > [email protected]<javaposse%2bunsubscr...@googlegroups
> > > > .com>
> > <javaposse%2bunsubscr...@googlegroups .com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<javaposse%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Cédric
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
