commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc <...@spaceroots.org>
Subject Re: [Math] LeastSquaresOptimizer Design
Date Thu, 24 Sep 2015 10:41:00 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

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


Mime
View raw message