commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject [collections] Proposal - Subpackages
Date Thu, 13 Nov 2003 00:38:59 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message