> 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 implementations to warrant a separate package? I don't think > so. A BidiMap is a special type of Map, so how about putting it in > o.a.c.c.map? I split the packages so most had a base interface and a Sorted subinterface in one. Thus Set and SortedSet are together, Map and SortedMap, Bag and SortedBag, and thus BidiMap and SortedBidiMap. Note that I deliberately did NOT propose a subpackage for each interface because I paired things like this.
The JDK List interface is not called 'ListCollection', or Set called 'SetCollection'. But they are both sufficiently large concepts to justify a subpackage. I guess it would be more obvious if BidiMap was called Bidi! Remember, that each interface and Sorted version comes with a set of decorator classes (predicated, sync, unmod,...). They haven't been written for bidi yet, but sometime they will be. > 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 > Stephen Colebourne wrote: > > A technical discussion - much more interesting than management debates..... > > > > I would like to propose a change of package structure within [collections] > > to an interface based subpackage structure. > > - collection > > - set > > - list > > - bag > > - buffer > > - map > > - bidimap > > I am proposing moving all the decorators and all the observable classes, > > plus all the bidimap classes to this new structure. Other classes can follow > > LATER. > > > > Reasoning: > > 1) [collections] contains two implementations of AbstractIteratorDecorator > > and AbstractListIteratorDecorator at present. This happened because it is > > unclear as to where these classes should reside - in iterators or > > decorators. > > > > The base interface is the simplest, most obvious division - 'I want a Map > > that....', so look in the map package. Its also the one used in previous > > releases with comparators/iterators. > > > > 2) [collections] has four ways to group classes at present - collection > > decorators, observed collections, comparators/iterators and other. This is > > very confusing. The previous two releases have created the comparators and > > iterators subpackages, now is the time to finish the job along the same > > lines. > > > > 3) The distinction between a decorator and a non-decorator is too fine for > > me, and non-obvious to the user. We already have the proposal that all > > decorators should have a default collection implementation, making them no > > different to a non-decorator implementation to the user. Also, some main > > implementations like HashBag/TreeBag/DualHashBidiMap are essentially > > decorators, but not in the decorators package. > > > > The decorators subpackage was created as a breakout of inner classes, not > > because it was a sensible component package design. Its unreleased, so lets > > fix the mistake NOW. > > > > 4) The MultiMap interface could do with reworking. By moving to a > > subpackage, the same name can be used but with a much better API (the > > interface in the main package can't be changed as its an interface). There > > is a similar problem with the Bag interface. > > > > Arguments against, and counter reasons: > > 1) 'Too much change' - But decorators and observed are unreleased. The > > BidiMap interface/classes are also unreleased. Now is the time to give them > > a proper home. Change is always painful, but deprecations will occur, and > > [collections] is way bigger than it was when it started. Note that I am not > > proposing moving every [collections] class at this point, only the > > decorators/observed/bidimaps. > > > > 2) 'Decorators are distinct and should be kept separate' - But the iterators > > subpackage already contains a mixture, and no-one is greatly bothered. > > 'Iterators' is a more important gropuing than 'decorators'. IMO it is > > clearer having the iterators together, rather than some iterators here and > > some there. > > > > 3) 'Subpackages collide' - But there is currently no collision that would > > cause a problem. No class can implement both Collection and Map. No class > > can implement both Set and List. Classes are always intended for one primary > > purpose. > > > > > > This may be controversial, I don't know. But to me, the current layout is > > now just perfectly ridiculous. It needs sorting and IMHO this is the best > > solution. (I will do the work) > > > > Stephen > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
