[...] CM is not intended to be a design pattern people should mimic. We are so bad at this
The crux is that the project's team is in effect not _interested_ in this. [And I admit that I had not understood it for a long time (hence the temptation to convince that it was important for *some* people).]
it would be a shame. No one in its right mind would copy or reuse this stuff. It is for internal use only
Then why is it so difficult to change (cf. all the nit-picking about backward-compatibility)? As was (relatively) recently discussed, we could "mark" some code "for internal use" and be free to break compatibility at any time, for the sake of (an attempt at) a better design.
and we don't even have the resources to manage it by ourselves
There are (maybe) other people (like Ole?) who would like to experiment with new design ideas (not new math algorithms!) but are repelled by the (overly) conservative development process which is mainly feature-driven (like in a commercial project, shall I dare to say).
so we can't consider it as a path people should follow as we are leading them. Here we would be leading them directly against the wall.
True, unfortunately. There is really no long-term design. Even short term (quasi-)decisions when they concern the library as a whole, are not followed by action (cf. "fluent API")...
[...]
Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org