Re: [lang] Markup stuff on lang???

[Paulo Gaspar <paulo.gaspar>]

Sorry Henri,


I don't mean that comparators or functors should be killed. I also think
that the markup stuff is quite useful, but it is weird to have it in
"lang". (There are still a lot of apps that do not use any kind of
markup.)

Some one talked about "themed" jars and I think that is the way to go.

Still, stuff like the Flat3Map just seems way to specific: maybe things
like the Flat3Map should just be placed in some code-snipets/classes
repository.

Again, what I mean is:
  - "if I do not use it, I should not have to carry it".

And this concern has MUCH more to do with the bulk of javadocs and
sources I have to handle while developing software than with the MBytes
of jars the JVM has to load when it runs the final product.


Thanks for your attention and have fun,
Paulo Gaspar



Henri Yandell wrote:

> 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 :)
> 
> Hen
> 
> 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 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.
>>
>>Examples of 2) that I DISlike:
>>- o.a.c.collections.map.Flat3Map??? 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
>>
...


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org