commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [all commons] Proposal: CommonsCommons package
Date Sun, 16 Jun 2002 09:35:29 GMT
From: "Ola Berg" <ola.berg@arkitema.se>
> >Architecture/patterns/design is fine, but in the end
> >we need code.
>
> True. I can supply code, implementing the patterns I have suggested (spent
last two years trying different methods to implement them).
>
> But consensus is needed at some level for others to use the common
implementations (I guess the commons project as a whole has the same
situation in relation to the other projects: \"Hey, use _our_ stuff
instead!\").
>
> What I said was (removing the words \'patterns\', \'architecture\' or
\'design\'): reach agreement on how a general thing is to be done. Without
the agreement between at least two component groups, the whole idea of
single implementation of the general mechanisms are of no use anyway.
>
> Java offers this possibility for fine grain binary object reuse. Done
right it translates into a massive heck of many things achieved with
absolutely minimal effort. And even if such an ideal case is never to
happen, one single general mechanism is a bargain.
>
> But it is dependent on 1) someone seeing how a certain mechanism could be
used in more contexts than now, and 2) everybody else\'s ability to
acknowledge what this person has seen.
>
> This will probably mean a slower pace. The role of such a \"general reuse
project\" is often to come in afterwards, suggesting refactoring of existing
API:s (not necessarily afterwards but in practice this is often the case).
If and only if the benefits of refactoring are so great that it is worth
doing, it will be done. If not, the whole idea is pointless in practice
(albeit fine in theory).

Just so we're clear, I do basically support the idea. And refactoring after
the 'first go' is a fairly typcial methodology as far as I am concerned.
I've contributed to the Predicate code before, and would do so again even if
it moved to lang. However, I am sure that it would annoy me (and the
committers) to have to patch everything in two places.

I suggest that you draw up a list of classes that you see as being put in
lang (seeing as you seem to be suggesting you have some of your own). That
way we might see what the finished lang would look like. I also think that
you need to define a one sentence 'what the package does'. Like collections
could be 'provide extensions and adaptors to the Java Collections API
compatable with J2SE 1.2'.

Finally, I think its significant that if you go to the collections website
it doesn't mention Predicate, Transformer or Closure - this kind of
emphasises their don't belong status.

Stephen



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


Mime
View raw message