The pattern used by TargetListener/TargetEvent seems simple and sensible to me, just extending EventListener and EventObject.
I think EventListenerList is generally recommended to hold reference to listeners. I don't know the details of why but I think there may be some level of thread safety provided. Bob. On 22/09/2008, Brian Hudson <[EMAIL PROTECTED]> wrote: > Linus was asking me about merging in some of the changes on my argouml-app > branch post 0.26 so this thread came up again. > > It seems that we've agreed on deprecating the central mechanism described in > this thread, and several people don't seem to like property events... so > with both of these out is there a new recommended approach to events in > ArgoUML? If so, I'd like to refactor my changes to utilize this before > merging them in. > > Thanks, > > Brian > > > On Mon, Jul 14, 2008 at 7:39 AM, Linus Tolke <[EMAIL PROTECTED]> wrote: > > > > Assuming the release is the 0.26 release and the recent addition are > things added this year or so I'd say that it is OK to go ahead as long as it > is done before the first beta that is now scheduled for next week. > > > > Do the following: > > * Create an issue for this if there isn't any. > > * Deprecate this centralized mechanism. > > * Do the changes to the recent additions to get them out of there into > their respective subsystem. Do these one at the time. > > * If there is more time left, move also the old code to their respective > subsystem, keeping the old notifications so that new code can use the new > way of doing it while old code is still working. Do these one at the time. > > > > This must be done before Tuesday 22nd. > > > > If there isn't time, there is a possibility to halt this at any step and > we will have a strangely mixed solution but we will have to live with that. > I hope this is feasable. > > > > > > > > > > /Linus > > > > > > 2008/7/14, Bob Tarling <[EMAIL PROTECTED]>: > > > Tom is the person who first asked this question and is the person who > > > can probably answer your question best. > > > > > > I'm just bumping the question up the list so that it does get done ASAP. > > > > > > Bob. > > > > > > > > > 2008/7/14 Linus Tolke <[EMAIL PROTECTED]>: > > > > Exactly what are you suggesting here Bob? In what timeframe and what > classes > > > > are affected? > > > > > > > > /Linus > > > > > > > > > > > > 2008/7/14, Bob Tarling <[EMAIL PROTECTED]>: > > > >> > > > >> Do you have a view on this Linus. > > > >> > > > >> Can we simplify the recently adding events and listeners? > > > >> > > > >> Bob. > > > >> > > > >> > > > >> 2008/7/9 Brian Hudson <[EMAIL PROTECTED]>: > > > >> > What then becomes the new recommended approach? > > > >> > > > > >> > I'd like to change the event mechanism I just added in my branch to > the > > > >> > new > > > >> > way before it gets merged into trunk. > > > >> > > > > >> > Brian > > > >> > > > > >> > On Tue, Jul 8, 2008 at 4:51 PM, Bob Tarling <[EMAIL PROTECTED]> > > > >> > wrote: > > > >> >> > > > >> >> > Unless someone comes up with a good reason it should stay, we > should > > > >> >> > deprecate this mechanism. The question is whether it's too late > to > > > >> >> > split out all the recent additions to the event pump and put > them > > > >> >> > some > > > >> >> > more reasonable place in the public API before the release. > > > >> >> > > > >> >> I would say go ahead and do this is we have agreement. This sounds > > > >> >> like simple refactoring and we don't really want to release > anything > > > >> >> now that we know we will deprecate later. > > > >> >> > > > >> >> Bob. > > > >> >> > > > >> >> > --------------------------------------------------------------------- > > > >> >> To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > > > >> >> > > > >> > > > > >> > > > > >> > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > >> > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
