> > what about something like [events]? > > > commons component named [notifying] quite sounds right. [notify] > maybe,
Unless we're talking about changing the scope of the project entirelyu, then any package name would have to include "collections" in it. That is, [observable-collections], [notifying-collections] etc.. My initial reaction to "events" is that the notification mechanisms don't have to be event based, it can also be via callback (i.e. there's no event object), but that could very well be splitting hairs. I think I would be all in favour of creating a sandbox project called [events] whose scope would be to provided support for event-based programming, including the observable/notifying collections implementations, and other utilities. For instance, the [notifyingcollections] implementation already had generic event classes that I had provisonally placed in a o.a.c.lang.event package, including an EventDispatcher interface, a SynchronousEventDispatcher implementation, an EventFilter interface etc. that are in no way tied to the collections-specific work. thoughts? >neil --- Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Its certainly short, snappy and to the point. One argument against > might be > it being a wide ranging term. > > Stephen > > ----- Original Message ----- > From: "__matthewHawthorne" <[EMAIL PROTECTED]> > > Is this "observable" project based on the concept of "events"? If > so, > > what about something like [events]? > > > > Also, there's always [observation]. > > > > > > > > > > Stephen Colebourne wrote: > > > Observable is named after the Observer pattern in my eyes. > Notifying is > OK > > > as a name, and possibly clearer in intent, however I'm not sure > that a > > > commons component named [notifying] quite sounds right. [notify] > maybe, > but > > > then thats not quite right either. > > > Any other naming views? > > > Stephen > > > > > > > > > ----- Original Message ----- > > > From: "Neil O'Toole" <[EMAIL PROTECTED]> > > > > > >>--- Stephen Colebourne <[EMAIL PROTECTED]> wrote: > > >> > > >>>We've had all positives so far. I'm going to take this as agreed > and > > >>>move > > >>>the code to a new sandbox project. I reckon [observable] is > probably > > >>>the > > >>>best name, although I'm open to offers. > > >> > > >>I don't have strongly held opinions on the naming, but I went > through > > >>the process of picking a name for a collections > > >>observable/notifying/eventsending/callbacking package, and I > figured > > >>I'd share the thoughts I had on it. > > >> > > >>Firstly, it certainly should be [observable] rather than > [observed], > > >>but I'm not going to pretend to remember enough about english > grammar > > >>to explain why [observable] is better :) > > >> > > >>I had originally considered this [observable] name when I set > about > > >>creating my implementation. One of the first things I did (this > was > > >>circa Sep 2002 I think) was search on the web to see if anybody > else > > >>had already implemented such a package. The snippet of text that > > >>decisively turned me away from the [observable] name was this: > > >> > > >> > > >>>Observability. An observable collection is one in which it is > > >> > > >>possible to view the elements in a collection. > > >> > > >> @ http://www.haskell.org/ghc/docs/edison/users007.html > > >> > > >>... which of course is the crux of the issue. The familiar > > >>implementations of the collections API are all observable, in > that you > > >>can examine the elements of the collection, such as via an > iterator. > > >>But the [notifying/observable] implementations we've developed > > >>*actively* signal information, typically when the collection > changes > > >>(although that is not necessarily the case - I could envisage an > > >>implementation that sends an event when the collection changes > *or* > > >>every X seconds, or when some other predicate is satisfied). > > >> > > >>So, rather than denoting passivity, I figured the name needed to > > >>indicate the "active signaling of state information by the object > being > > >>observed". A snappier name for this behaviour is "notification", > so I > > >>went with the name [notifyingcollections] over > [observablecollections]. > > >>You also save a letter in typing ;) > > >> > > >>Though I don't feel very strongly about it, I still believe that > > >>[notifying] is a more indicative name than [observable], and I > would > > >>suggest we use it. However, I still have a sneaking suspicion > that > > >>there is a fugitive word out there that better captures the > essence of > > >>the "active signalling of state information by the object being > > >>observed", so hats off to anyone who can conjure it up :) > > >> > > >> > > >>>neil > > >> > > > >>--------------------------------------------------------------------- > > >>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]
