+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 furth
+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]
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 deco
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
Scott Colebourne wrote:
>
>
> 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
> > functiona
> 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 implem
> from:Arun Thomas <[EMAIL PROTECTED]>
> Any chance you could provide a package dependency diagram (in text is fine) for the
> structure you envision? Are there any commons conventions on such dependencies?
In essence the package dependencies are as you would expect.
collection depends on
