Hi Gilles,
Le 2015-09-23 23:00, Gilles a écrit :
[...]
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.
I think it would be nice. IMHO, we are overzealous on compatibility.
Sometimes, I try to introduce some changes that may break compatibility
early for some non user-implementable interfaces but have to withdraw
my proposal (tried it for ode, tried ot for BSP trees, think I tried it
for optimizers).
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).
Surely. But it is not specifically commercial vs open source I think.
I know commercial projects that break compatibility all the time
(perhaps
to force users buying a new licence) and some that are stable. I know
open-source projects that break compatibility all the time (perhaps
because the team is highly dynamic or doesn't care about users) and
some that are stable.
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")...
I still have fluent API in my TODO list and still really wants to make
it appear. The major blocking factor is available time (and sometimes
also despair about probable endless forthcoming discussions but it is
only second in the list).
best regards,
Luc
[...]
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
