Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <20031128225457.27569.qmail@web14103.mail.yahoo.com>
Date: Fri, 28 Nov 2003 14:54:57 -0800 (PST)
From: Neil O'Toole <neilotoole@yahoo.com>
Subject: Re: [collections][PROPOSAL] Remove Observable subpackage
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <005901c3b53a$4ade0220$4a7d8051@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> > 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 <scolebourne@btopenworld.com> 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" <matth@phreaker.net>
> > 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" <neilotoole@users.sourceforge.net>
> > >
> > >>--- Stephen Colebourne <scolebourne@btopenworld.com> 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:
> commons-dev-unsubscribe@jakarta.apache.org
> > >>For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org