commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <arun.tho...@paybytouch.com>
Subject RE: [collections] Proposal - Subpackages
Date Thu, 13 Nov 2003 01:17:13 GMT
Stephen, 

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?  

-AMT

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
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