commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] Size and scope issues
Date Mon, 19 Apr 2004 21:02:02 GMT
Well, what is nice is to have at least SOME feedback. Often we hear of
comments made, without actually coming back here and telling us what is
wrong (or letting us explain). See inline:

From: "paulo gaspar" <"paulo gaspar">
> IMO, the collections package:
> 1) should have really commonly used collections that are missing on the
> java.util package and also
>     some usefull collections building blocks for especial cases;
> 2) should NOT be a contest to implement all possible classes that have
> something to do (even
>     remotedly) with collections, doesn't mater how special they might be.
#1 is not a bad aim for [collections], the trouble is everyone will define
it differently. And always remember that [collections] was originally just a
dumping ground for other peoples collections. Only now is it starting to
become complete in its own right. #2 is perception, rather than reality
IMHO.

> Examples of 1) that I like:
> - The o.a.c.collections.map.Abstract* classes, which are very useful
> building blocks;
> - o.a.c.collections.map.TypedMap, which solves a very common problem,
> before we all use JDK1.5.
Great! But I'll bet that others would say the TypedMap shouldn't exist at
all. And BTW, TypedMap uses PredicatedMap as its implementation, so they're
included too;-)

> Examples of 2) that I DISlike:
> - o.a.c.collections.map.Flat3Map??? WTF? How many humans use that?
Well I know it is in use as I've had, and fixed, a bug report against it. If
you want a small map that is very memory, performance and garbage collector
efficient this is it.

> - ALL the Unmodifiable crap, since its only advantage over the
>    java.util.Collections.unmodifiable*() methods is the Unmodifiable
> marker interface, and that
>    (the marker interface) is something most apps don't need, and for
> those who need, it is easy to implement;
I can understand this. The reason the classes exist is for completeness and
practicality. [collections] has interfaces that are not in the JDK, and they
need unmodifiable decorators (which aren't in the JDK). Since these 'extra
interface' unmodifiable classes got written it made sense to complete the
set - also, the map implementations often need Set and Collection
implementations anyway. Finally, there is the ability to add a little extra
functionality - Unmodifiable, and support for extracting the decorated
collection to recreate the BoundedCollection interface (try doing that with
the JDK).

> - All the o.a.c.collections.functors stuff. This is stuff for a very
> specific class of apps! Most
>    useful uses of this sh*t are related with tools that have some
> visual/xml/whatever way of
>    composing things. Way soes the rest of the human race have to put up
> with all of this?
History. [collections] has had functors in from the start. I would never
have added them, but they came before my time (a separate commons project
for all the functor stuff would have made more sense). However, as they were
in there we had repeated requests for default implementations, so they got
added. Would you deny user requests?

> - The o.a.c.collections.comparators. Just like the above. Even because
> comparators SHOULD
>    be very performant since they tend to be called many times in on
> single action. More often
>    than not, it is faster and easier to just write your own comparator
> than to compose one out
>    of this stuff. And I DO things that could use a ComparatorChain and
> most of the others, but
>    I would rather not have them there.
> - ...and I could go on for a while like this...
Fine, you use one, but you might use another. [collections] can't judge
based on what one user wants, but on what the balance of users want. And
again, comparators have existed in [collections] right from the start.


> IMO, what would make sence would be to have:
> 1) A core Collections package with the really common stuff + building
> blocks that ease the work
>     of building custom/specific collections related stuff;
> 2) A repository of the weird packages where anyone could pick one of the
> less common bits.
>
> I don't care if there are more little collection bits, either as
> multiple collections packaged bits or
> as a packaged JAR/Docs + a repository. IF it is clearly documented what
> is the purpose of each
> bit that makes my life easier, because then I will only pick the bit
> that matters to me and its doc,
> and I will have less "noise"(*) to deal with.
The key phrase here is 'with the really common stuff'. Who defines that?

I would argue that we already do that. Remember, that code for primitive
collections was removed from [collections] - if that hadn't have been done,
[collections] could have been twice its current size. Also [events] code was
removed, as it was non-mainstream and could standalone.

Whereas, the functor code tried to find a home in numerous other places, but
in the end only [collections] was appropriate and supported by the commons
community.

BTW, some suggested additions to collections have been rejected - Trie for
example. Its always a fine balance.


Having said all that, it must be born in mind that [collections], like
[lang], operates in two ways. The first is as a jar file dependency. For
that it requires a good package layout, complete and logical set of classes
(no holes) and clear docs.

The second usage is as a cut and paste of individual classes to other
projects. This is happening with [beanutils] and [digester] where they only
ever referred to one or two collection classes and the dependency was alway
ridiculous. I have no problem with taking a collection class and embedding
it in another project, so long as the license conditions are met and the
package name is changed.

Anyway, as I said at the start, its good to have the feedback, even if you
believe that we have it totally wrong ;-)

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