> 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 iterators list depends on collection and iterators set depends on collection and iterators bag depends on collection and iterators buffer depends on collection and iterators map depends on iterators, and probably set and collection bidimap depends on map, iterators, and probably set and collection This isn't that different to the current CVS, where there are already dependencies between decorators and iterators and the main package. I don't know of any conventions regarding this, although [lang] certainly has multiple small subpackages which inter-depend. Stephen > -----Original Message----- > 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 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]
