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 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
