Just like EventListener, ArgoEventListener (which extends EventListener) is just a tagging/marker interface.
I don't see any advantage in extending EventListener. If ArgoEventPump used an EventListenerList I could see the need to extend EventListener, but it doesn't it uses a List<Pair>. I believe that EventListener/EventObject were created to add a little type safety to event handling before generics were added. I just checked in some changes to my branch which fire events when diagrams are added/removed from a project. Having dealt with these classes now I still don't see the advantage in having the central event registry. What really surprised me when adding in this functionality was that I had to modify ArgoEventPump to handle the firing of my specific events. So in ProjectImpl, I fire off a diagram added event, but then in ArgoEventPump I needed to detect it was a ArgoProjectEvent, then figure out again that it was a diagram added event (opposed to a remove) so I could then call the correct method on the ArgoProjectListener... The only thing I think all of this saved me from doing is adding addListener/removeListener methods to the class/interface I was trying to observe - but I'm not sure I'd consider that an advantage because I find it more intuitive to add the listeners to the object I am actually trying to observe. On Tue, Jul 8, 2008 at 2:55 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > This conversation doesn't seem to have gone on any further. > > Can anyone explain to me what the advantages are of extending > ArgoEventListener etc rather than just extending EventListener, > EventObject? > > Bob. > > > 2008/6/30 Bob Tarling <[EMAIL PROTECTED]>: > >> As you've discovered, we've got a few conventions. :-) Some things > >> extend ArgoEventListener in an event-specific manner and others > >> implement PropertyChangeListener directly. Generally I prefer the > >> former style, but I'm not really thrilled with the central event types > >> registry in ArgoEventTypes since this seems to introduce more coupling > >> than is desirable. Having said that, I think extending > >> ArgoEventListener is the right way to go for this since it will keep > >> things consistent. What do others think? > > > > I really don't like the way we've used PropertyChangedEvent, I think > > that was not the best decision for listening to changes from the model > > subsystem. It makes a class that's listening poorly self-documenting > > as it's not actually clear what it is interested in listening to. It > > can also result in bloated methods dealing with too events from > > different subsystems. > > > > I'm don't know what advantage there is of having our own base events > > and listeners or a central registry. Just extending EventListener and > > EventObject I would have thought would be fine. But then we have a > > third way. > > > > Bob. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > On Tue, Jul 8, 2008 at 2:55 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > This conversation doesn't seem to have gone on any further. > > Can anyone explain to me what the advantages are of extending > ArgoEventListener etc rather than just extending EventListener, > EventObject? > > Bob. > > > 2008/6/30 Bob Tarling <[EMAIL PROTECTED]>: > >> As you've discovered, we've got a few conventions. :-) Some things > >> extend ArgoEventListener in an event-specific manner and others > >> implement PropertyChangeListener directly. Generally I prefer the > >> former style, but I'm not really thrilled with the central event types > >> registry in ArgoEventTypes since this seems to introduce more coupling > >> than is desirable. Having said that, I think extending > >> ArgoEventListener is the right way to go for this since it will keep > >> things consistent. What do others think? > > > > I really don't like the way we've used PropertyChangedEvent, I think > > that was not the best decision for listening to changes from the model > > subsystem. It makes a class that's listening poorly self-documenting > > as it's not actually clear what it is interested in listening to. It > > can also result in bloated methods dealing with too events from > > different subsystems. > > > > I'm don't know what advantage there is of having our own base events > > and listeners or a central registry. Just extending EventListener and > > EventObject I would have thought would be fine. But then we have a > > third way. > > > > Bob. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
