I was planning on allowing the broader scope, not just restricting to collections. So [events] is quite a good name. I'll probably go with this unless I hear a much better name.
Stephen ----- Original Message ----- From: "Neil O'Toole" <[EMAIL PROTECTED]> > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
