Scott Colebourne wrote:

> <snip>
>
> Matthew Hawthorne wrote:
>
> > I also disagree with moving the observable classes.  The way I see it,
> > the desire for a collection that is observable overrides a desire for a
> > specific collection type.  The observable classes represent a distinct
> > functionality, and splitting them across the suggested packages seems
> > confusing to me.  Plus, it seems we would still need an observed or
> > observable package - else, what package would ModificationEvent and
> > ModificationHandler go in?
> >
> > The observable classes are used together, will change together, so why
> > not package them together?  The problem with this is that it doesn't
> > follow your suggested standard structure - but I think it has a good
> > reason not to.
> If split into the packages, there would have to be an events package with
> the common event code. Actually, the observed package is one of those
> parts of [collections] like primitives that is more independent.
>
> Observable does seem to have the potential to be popular. (I've received
> various communications about it.) One possibility might be to create a
> new jakarta-commons project for it like primitives. Although that does
> seem a little extreme, it might allow it to grow and include other JDK
> integration classes for example.
>
> Stephen

I think I would support a move of the Observable classes to a separate
project, but I feel that moves the release that much further away.

In addition to the existing implementations, I would also like to see
Observable maps, primitive collections, and Colt 2D and 3D matrices.  The
latter I was planning to implement in a separate repository after the
observable classes in commons were released.

   michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to