commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] Markup stuff on lang???
Date Sun, 25 Apr 2004 01:51:02 GMT

It is opinion based though. While I'm not against your 3Map, Unmodifiable
and Functor arguments, I'm very against the comparator argument.

Writing custom comparators all the time is a big waste of development time
that I see all the time. They do not normally need to be performant to
that extent.

I can happily verify this by the number of times I apply BeanComparator,
which uses reflection and is obviously at the slow end of performance.

All of this shows that design by community can tend to larger APIs than
design by sole-need. One of Hani's complaints has been the sheer number of
jars at Commons, though I can't be arsed to find a reference so that might
be wrong :)


On Mon, 19 Apr 2004, paulo gaspar wrote:

> Hi Stephen,
> Man, this is about [lang]. Don't even get me started on the Collections
> front or it will look like one
> of Hani's posts on the Bile Blog...
> ...well, can't resist:
> 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.
> First the nasty and then I will try to be CONSTRUCTIVE:
> Examples of 1) that I like:
> - The* classes, which are very useful
> building blocks;
> -, which solves a very common problem,
> before we all use
>    JDK1.5.
> Examples of 2) that I DISlike:
> - WTF? How many humans use that?
> - 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;
> - 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?
> - 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...
> Switching "constructive mode" ON:
> 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.
> (*) Anything I don't really need when navigating trough docs or source
> is a kind of noise, even if
>       it could be useful in another context.
> Have fun,
> Paulo Gaspar
> Stephen Colebourne wrote:
> >From: "paulo gaspar" <"paulo gaspar">
> >
> >
> >>I am just afraid that lang will become a > 800KB jar, like collections
> >>already is. =:o/
> >>
> >>
> >
> >Do you have a specific complaint wrt this? [collections] has already split
> >into 3, removing primitives and events code. Where and how does the size
> >cause an issue?
> >
> >Stephen
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> >For additional commands, e-mail:
> >
> >
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message