commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [all commons] Proposal: CommonsCommons package
Date Sat, 15 Jun 2002 23:23:57 GMT
From: "Ola Berg" <>
{snipped lots of arguments about why this is A Good Thing}
{snipped because basically I agree, I'm more concerned about practicality}
> So I think the steps would be like
> 1) Creating this general package from what we have seen is general.

If it is to be lang, this would involve increasing its awareness level. I
was a little harsh earlier in suggesting nothing was going on there. The CVS
says that the last change was 11 days ago. It would also involve
establishing if any other projects are currently using/dependent on lang.
I'm trying to hint that we might need to change the public API of what is
currently there, since its sandbox it shouldn't matter ;-). (It's the
Constant class I'm most worried about)  It would also need more tests

> 2) Offer patches to the other component groups, for the proof of
> concept.
> 3) Modify according to the thoughts of the component groups
> 4) In the process: move at a slow pace, always discuss every change
> etc. Regard it as a thing for the future, and don\'t hurry.

I think that if this proposal is to get started, it needs the Predicate,
Transform, Closure and Factory classes from collections (amended if
necessary). This requires agreement from collections as its not backwardsly
compatable (there are ways to make it so, but I think they confuse not
simplify). Without the agreement to move (not necessarily immediately, but a
commitment to move at some point), IMHO the improved lang wouldn't get

This also affects Identifiable, which isn't yet in betwixt, but could be
soon, and then soon after into a release. Thus there is a time factor there.
(The answer may be to not put the feature into betwixt yet).

> 5) Discuss at a patterns level. Take the Exception handling
> discussion: there is a need for patterns how to handle Exceptions in
> different contexts. Once you agree on a pattern, a generic
> implementation would easily follow, so don\'t make the generic
> implementation until you have reached some kind of consensus on what
> patterns catalogue the generic packages should support.

Architecture/patterns/design is fine, but in the end we need code.
Consensus is fine, so long as a decision _is_ reached in a _reasonable_
amount of time.

It also requires consideration of timescales for promoting lang out of the


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

View raw message