+1 on the package hierarchy. I especially agree with:
3) The distinction between a decorator and a non-decorator is too
fine for me, and non-obvious to the user.
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
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,
From: Michael Heuer [EMAIL PROTECTED]
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
I am intending to proceed with this on Sunday all being well, unless I hear
objections...
Stephen
- Original Message -
From: [EMAIL PROTECTED]
from:__matthewHawthorne [EMAIL PROTECTED]
Packages for collection, set, list, buffer, bag, and map look good to
me. The decorators
+1
Stephen Colebourne wrote:
I am intending to proceed with this on Sunday all being well, unless I hear
objections...
Stephen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 4:39 PM
To: Jakarta Commons Developers List
Subject: [collections] Proposal - Subpackages
A technical discussion - much more interesting than management debates.
I would like to propose
from:__matthewHawthorne [EMAIL PROTECTED]
Packages for collection, set, list, buffer, bag, and map look good to
me. The decorators package can just be split up and categorized
accordingly.
However, I disagree with a few things. For example, are there enough
BidiMap
