You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/11/25 00:10:09 UTC
[collections][PROPOSAL] Remove Observable subpackage
I would like to propose that the observable subpackage of [collections] be
removed to another location. It remains a relatively self contained part of
[collections] following the recent restructuring, and has the potential to
grow with other event strategies and integration with GUIs such as Swing.
This makes it a relatively poor fit with the rest of [collections].
Either the sandbox, or sourceforge seem appropriate for the code. I know
there is demand for the code and a release, but I don't want to let it lie
unreleased in [collections] as primitives did for far too long.
So, whos in favour of removing it from [collections]?
And where to, sandbox (observable), sourceforge (joda-observable), or
elsewhere?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Neil O'Toole <ne...@yahoo.com>.
--- __matthewHawthorne <ma...@phreaker.net> wrote:
> I think it's a good idea to remove it. At this point, [collections]
> is
> so big that I'm +1 for removing all that we can. I frequently get
> OutOfMemoryExceptions when doing the maven build due to the size
> (from
> the statcvs and linkcheck plugins).
>
> Now as to where it should go, I always like the idea of doing it at
> Apache if possible.
Amen on that.
> Here's an idea:
>
> Perhaps it's time for collections to become a larger project which
> can
> contain subprojects. I'm not sure if this is doable in Jakarta
> Commons,
> but maybe in top-level Jakarta or the newer Apache Commons?
>
> I realize that this is a semi-radical idea, but maybe it's worth
> considering? At a minimum, I think it would provide the newer
> subprojects with more visibility and possible promote a more active
> community.
I think that's well worthy of consideration. Three [collections]
projects perhaps should entitle [collections] to it's own project
hierarchy, and I think it's vitally important to keep these projects
under the same roof rather than have them skulk off to the dark corners
of sourceforge where who knows what will become of them? ;)
>neil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by __matthewHawthorne <ma...@phreaker.net>.
I think it's a good idea to remove it. At this point, [collections] is
so big that I'm +1 for removing all that we can. I frequently get
OutOfMemoryExceptions when doing the maven build due to the size (from
the statcvs and linkcheck plugins).
Now as to where it should go, I always like the idea of doing it at
Apache if possible.
Here's an idea:
[collections] has already spawned off another subproject in
[primitives]. There is the alternative primitive collections (let's
call it [primitives2], I forget what the actual name is) that you have
at SourceForge, and now the possibility of [observable]. However, all
of these projects, in a way, still fall under the domain of [collections].
Perhaps it's time for collections to become a larger project which can
contain subprojects. I'm not sure if this is doable in Jakarta Commons,
but maybe in top-level Jakarta or the newer Apache Commons?
All administrative burdens aside, this makes more sense to me. The
current [collections] could become [collections-core], along with the
newer [collections-primitives] and [collections-observable]. This
would allow proper room to grow for each subproject -- while still
keeping related projects together.
I realize that this is a semi-radical idea, but maybe it's worth
considering? At a minimum, I think it would provide the newer
subprojects with more visibility and possible promote a more active
community.
Stephen Colebourne wrote:
> I would like to propose that the observable subpackage of [collections] be
> removed to another location. It remains a relatively self contained part of
> [collections] following the recent restructuring, and has the potential to
> grow with other event strategies and integration with GUIs such as Swing.
> This makes it a relatively poor fit with the rest of [collections].
>
> Either the sandbox, or sourceforge seem appropriate for the code. I know
> there is demand for the code and a release, but I don't want to let it lie
> unreleased in [collections] as primitives did for far too long.
>
> So, whos in favour of removing it from [collections]?
> And where to, sandbox (observable), sourceforge (joda-observable), or
> elsewhere?
>
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by __matthewHawthorne <ma...@phreaker.net>.
True, but when the codebase is somewhat standalone (as observable and
primitives2 are), and the tests and scope are different, I think that a
heirachy of projects is worth considering, especially given the current
size of [collections].
When producing multiple jars, does it make sense to keep everything in
the same source tree? I say no, for mostly organizational reasons, but
perhaps others see it differently...?
Henri Yandell wrote:
>
> On Mon, 24 Nov 2003, Stephen Colebourne wrote:
>
>
>>So, whos in favour of removing it from [collections]?
>>And where to, sandbox (observable), sourceforge (joda-observable), or
>>elsewhere?
>
>
> I'm +1 on it moving out. Who is the community as far as that piece of code
> is concerned? Is it just a Stephen Colebourne work, ie) moving to joda
> makes good sense, or something by more people?
>
> As far as making Collections a 'SLP' of Jakarta, I think it would be
> better to keep it in Jakara Commons and just have sibling projects. Or
> have multiple jars being built by the Collections project. Just because it
> has multiple jars doesn't mean it's a n umbrella project.
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Neil O'Toole <ne...@users.sourceforge.net>.
I would very much like to have access to the sandbox for this. Lack of
access to the observable package in [collections] has certainly been an
obstacle and demotivating factor to integrating the
[notifyingcollections] features with the observable package in
[collections], something which has been on the long finger for too long
:) I also feel that Michael should be part of this sandbox project as
his contributions had a large part to play in getting the ball rolling
on these implementations - and certainly helped me improve the design
of the [notifyingcollections] implementation -, so I would think that
he should be considered one of the 3 developers required for a
subproject.
>neil
--- Michael Heuer <he...@acm.org> wrote:
>
> As a consideration, I believe that neither Neil nor myself have
> commit
> access to the commons sandbox. That isn't a show stopper for me
> because I
> haven't contributed all that much, but maybe Neil feels otherwise?
>
> +0
>
> michael
>
>
> On Tue, 25 Nov 2003, Stephen Colebourne 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. The move will probably
> happen late
> > this week/weekend unless someone objects.
> >
> > Stephen
> >
> >
> > ----- Original Message -----
> > From: "Neil O'Toole" <ne...@users.sourceforge.net>
> > > --- Henri Yandell <ba...@generationjava.com> wrote:
> > > >
> > > > I'm +1 on it moving out. Who is the community as far as that
> piece of
> > > > code
> > > > is concerned? Is it just a Stephen Colebourne work, ie) moving
> to
> > > > joda
> > > > makes good sense, or something by more people?
> > >
> > > Stephen, Michael Hauer, and myself are the three people who have
> had
> > > most involvement in this area. Stephen wrote the observable
> > > implementation. I'd developed another full implementation called
> > > notifyingcollections with a different slant. I don't have strong
> > > feelings on having separate source trees / projects (+0?) but the
> > > observable stuff should certainly have its own distributable.
> There are
> > > many equally valid ways of doing notification (in particular
> callback
> > > vs. event-based, and light event vs. heavy event), and novel
> features
> > > that can be added (such as the "ReplayableEvent" mechanism in
> > > notifyingcollections that allows an event to be undone/replayed
> in an
> > > arbitrary manner thus enable the easy recording of the entire
> state
> > > history of a collection). In short, lots of code.
> > >
> > > I really think it does deserve its own distributable, and the
> more I
> > > think about it, probably it's own subproject. I believe one of
> the
> > > points that Steven was making is that this work is holding up the
> > > release of the core [collections] stuff. And since there's so
> much that
> > > can be done in [observable], I feel it would be fairer to
> decouple the
> > > pair.
> > >
> > > >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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Michael Heuer <he...@acm.org>.
As a consideration, I believe that neither Neil nor myself have commit
access to the commons sandbox. That isn't a show stopper for me because I
haven't contributed all that much, but maybe Neil feels otherwise?
+0
michael
On Tue, 25 Nov 2003, Stephen Colebourne 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. The move will probably happen late
> this week/weekend unless someone objects.
>
> Stephen
>
>
> ----- Original Message -----
> From: "Neil O'Toole" <ne...@users.sourceforge.net>
> > --- Henri Yandell <ba...@generationjava.com> wrote:
> > >
> > > I'm +1 on it moving out. Who is the community as far as that piece of
> > > code
> > > is concerned? Is it just a Stephen Colebourne work, ie) moving to
> > > joda
> > > makes good sense, or something by more people?
> >
> > Stephen, Michael Hauer, and myself are the three people who have had
> > most involvement in this area. Stephen wrote the observable
> > implementation. I'd developed another full implementation called
> > notifyingcollections with a different slant. I don't have strong
> > feelings on having separate source trees / projects (+0?) but the
> > observable stuff should certainly have its own distributable. There are
> > many equally valid ways of doing notification (in particular callback
> > vs. event-based, and light event vs. heavy event), and novel features
> > that can be added (such as the "ReplayableEvent" mechanism in
> > notifyingcollections that allows an event to be undone/replayed in an
> > arbitrary manner thus enable the easy recording of the entire state
> > history of a collection). In short, lots of code.
> >
> > I really think it does deserve its own distributable, and the more I
> > think about it, probably it's own subproject. I believe one of the
> > points that Steven was making is that this work is holding up the
> > release of the core [collections] stuff. And since there's so much that
> > can be done in [observable], I feel it would be fairer to decouple the
> > pair.
> >
> > >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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ne...@yahoo.com>
> > > 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 <sc...@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" <ma...@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" <ne...@users.sourceforge.net>
> > > >
> > > >>--- Stephen Colebourne <sc...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Neil O'Toole <ne...@yahoo.com>.
> > 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 <sc...@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" <ma...@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" <ne...@users.sourceforge.net>
> > >
> > >>--- Stephen Colebourne <sc...@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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Its certainly short, snappy and to the point. One argument against might be
it being a wide ranging term.
Stephen
----- Original Message -----
From: "__matthewHawthorne" <ma...@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" <ne...@users.sourceforge.net>
> >
> >>--- Stephen Colebourne <sc...@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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by __matthewHawthorne <ma...@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" <ne...@users.sourceforge.net>
>
>>--- Stephen Colebourne <sc...@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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ne...@users.sourceforge.net>
> --- Stephen Colebourne <sc...@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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Neil O'Toole <ne...@users.sourceforge.net>.
--- Stephen Colebourne <sc...@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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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. The move will probably happen late
this week/weekend unless someone objects.
Stephen
----- Original Message -----
From: "Neil O'Toole" <ne...@users.sourceforge.net>
> --- Henri Yandell <ba...@generationjava.com> wrote:
> >
> > I'm +1 on it moving out. Who is the community as far as that piece of
> > code
> > is concerned? Is it just a Stephen Colebourne work, ie) moving to
> > joda
> > makes good sense, or something by more people?
>
> Stephen, Michael Hauer, and myself are the three people who have had
> most involvement in this area. Stephen wrote the observable
> implementation. I'd developed another full implementation called
> notifyingcollections with a different slant. I don't have strong
> feelings on having separate source trees / projects (+0?) but the
> observable stuff should certainly have its own distributable. There are
> many equally valid ways of doing notification (in particular callback
> vs. event-based, and light event vs. heavy event), and novel features
> that can be added (such as the "ReplayableEvent" mechanism in
> notifyingcollections that allows an event to be undone/replayed in an
> arbitrary manner thus enable the easy recording of the entire state
> history of a collection). In short, lots of code.
>
> I really think it does deserve its own distributable, and the more I
> think about it, probably it's own subproject. I believe one of the
> points that Steven was making is that this work is holding up the
> release of the core [collections] stuff. And since there's so much that
> can be done in [observable], I feel it would be fairer to decouple the
> pair.
>
> >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
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Neil O'Toole <ne...@users.sourceforge.net>.
--- Henri Yandell <ba...@generationjava.com> wrote:
>
> I'm +1 on it moving out. Who is the community as far as that piece of
> code
> is concerned? Is it just a Stephen Colebourne work, ie) moving to
> joda
> makes good sense, or something by more people?
Stephen, Michael Hauer, and myself are the three people who have had
most involvement in this area. Stephen wrote the observable
implementation. I'd developed another full implementation called
notifyingcollections with a different slant. I don't have strong
feelings on having separate source trees / projects (+0?) but the
observable stuff should certainly have its own distributable. There are
many equally valid ways of doing notification (in particular callback
vs. event-based, and light event vs. heavy event), and novel features
that can be added (such as the "ReplayableEvent" mechanism in
notifyingcollections that allows an event to be undone/replayed in an
arbitrary manner thus enable the easy recording of the entire state
history of a collection). In short, lots of code.
I really think it does deserve its own distributable, and the more I
think about it, probably it's own subproject. I believe one of the
points that Steven was making is that this work is holding up the
release of the core [collections] stuff. And since there's so much that
can be done in [observable], I feel it would be fairer to decouple the
pair.
>neil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections][PROPOSAL] Remove Observable subpackage
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 24 Nov 2003, Stephen Colebourne wrote:
> So, whos in favour of removing it from [collections]?
> And where to, sandbox (observable), sourceforge (joda-observable), or
> elsewhere?
I'm +1 on it moving out. Who is the community as far as that piece of code
is concerned? Is it just a Stephen Colebourne work, ie) moving to joda
makes good sense, or something by more people?
As far as making Collections a 'SLP' of Jakarta, I think it would be
better to keep it in Jakara Commons and just have sibling projects. Or
have multiple jars being built by the Collections project. Just because it
has multiple jars doesn't mean it's a n umbrella project.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org