...
From: "paulo gaspar" <"paulo gaspar">Yeah, #1 is good... in principle. =;o)
IMO, the collections package:#1 is not a bad aim for [collections], the trouble is everyone will define
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.
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.
...but #2 is a very strong perception, smelling like "real reality", to me.
By need or paranoia, many people will use a "TypedMap" repeatedly if they know they have one.Examples of 1) that I like:Great! But I'll bet that others would say the TypedMap shouldn't exist at
- 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.
all. And BTW, TypedMap uses PredicatedMap as its implementation, so they're
included too;-)
But having a Predicate interface does NOT mean you need to have all those functors!!!
I am sure all the weirdest collections were used at least once. But should that be enough?Examples of 2) that I DISlike:Well I know it is in use as I've had, and fixed, a bug report against it. If
- o.a.c.collections.map.Flat3Map??? WTF? How many humans use that?
you want a small map that is very memory, performance and garbage collector
efficient this is it.
I already told you that I already had use for a couple of the weirdest collections in this package,
BUT I still think they are not worth being there.
But ONLY those not-in-JDK need unmodifiable decorators.- ALL the Unmodifiable crap, since its only advantage over theI can understand this. The reason the classes exist is for completeness and
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;
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).
Completness is often a weak reason for too much featuritis/crap.
I am not sure that being able to extract the decorated object is a feature. I would qualify it as a Bug
in most of the contexts where I use such thing.
- E.g.: in a IoC design, if I give to some component a UnmodifiableMap it is usually because I
REALLY, REALLY want to avoid any possibility of that component's code being able to change
the decorated Map.
I am not saying that you should deny anything. What I am saying is that you should not impose so- All the o.a.c.collections.functors stuff. This is stuff for a veryHistory. [collections] has had functors in from the start. I would never
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?
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?
much.
This means that I am not against having even the incredible Flat3Map packaged in some way. My
problem is that I am overloaded with so much stuff if I want to use the most "obvious" and
"common" collections.
My dream is that Collections would be split in smaller subprojects, corresponding to smaller
packages (and docs/javadocs) to deal with. A big all-in-one package, compatible with the current
monster-jar should still exist.
I would just like to have an easy "standard" alternative to the monster jar.
- The o.a.c.collections.comparators. Just like the above. Even becauseFine, you use one, but you might use another. [collections] can't judge
comparators SHOULD
...
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, dividing would still make everybody happy. =:o)
Dividing with care, by "theme", can also solve this.
IMO, what would make sence would be to have:The key phrase here is 'with the really common stuff'. Who defines that?
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 was not implying this is easy. There is a reason why I became so quiet here during the last couple
BTW, some suggested additions to collections have been rejected - Trie for
example. Its always a fine balance.
of years...
=;o)
Having said all that, it must be born in mind that [collections], likeThis (no holes) thing is also something that must be taken with a grain of salt...
[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 otherThe license warrants that possibility, of course.
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 youI never meant that (the "tottaly wrong" bit)..
believe that we have it totally wrong ;-)
And I see improvement since last time I looked at collections with some attention (when the
primitives stuff was still on the mix and so), which was a really scary experience!
Now it was not so bad! =;o)
Seriously, not only do I see the primites out, but I also have the idea that everything is better
placed and fits better together. Last time I was just going to quit using Collections, now I am taking
the time to bother you into providing alternative packaging.
=:oD
StephenPaulo Gaspar
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
