commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Thu, 14 Jul 2011 09:46:13 GMT
Thanks Luc and Ted,
that's clear enough.
I'm looking forward to keep on working on linear operators and iterative 
solvers when I'm back.
Sebastien

Le 14/07/11 10:24, Luc Maisonobe a écrit :
> Hi Sébastien,
>
> Le 14/07/2011 09:44, Ted Dunning a écrit :
>> Because when the interface changes, an abstract class can add default
>> implementations (even if the implementations only throw unimplemented
>> operation exceptions).
>>
>> That means that code that has used the abstract class won't have to 
>> break.
>>   If you change an interface, the implementing code inevitably breaks.
>
> To explain a little further what Ted means above, [math] tries to keep 
> compatibility between releases, except for major releases. We have 
> already been hit by interfaces problems due to this management rule: 
> we did a wrong design on interfaces, but could not fix our errors 
> without breaking compatibilities. With abstract classes, when the 
> error was simply something forgotten, it is easy to add without 
> breaking existing user implementation that extend this: they will 
> inherit the added method implementation when they are compiled against 
> the new version of [math].
>
> This does not mean interfaces are evil and should be avoided. There 
> are many places where interfaces are very well suited. One of the use 
> of interface we still promote is for user code that represent some 
> problem to be passed to a [math] algorithm. Examples are functions 
> that are passed to root solvers or integrators (interface 
> UnivariateRealFunction and similar), ordinary differential equations 
> (interface FirstOrederDifferentialEquation), visitors for matrices 
> elements (interface RealMatrixChangingVisitor and similar) ... In 
> these cases, we really have nothing we can implement at [math] level 
> and more importantly the user object will implement our [math] 
> interface, but they still have the freedom to extend some other user 
> base class at the same time, to suit user needs. forcing user to 
> extend a [math] abstract class in this case would really be cumbersome 
> for users.
>
> So you see there is no silver bullet, sometimes we use interface, 
> sometimes we don't. We used a lot more interfaces before and are 
> changing our minds on some use cases.
>
> best regards,
> Luc
>
>>
>> 2011/7/13 Sébastien Brisard<sebastien.brisard@m4x.org>
>>
>>> We would then have had an empty abstract class. So why not an 
>>> interface?
>>
>
>
> ---------------------------------------------------------------------
> 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