commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
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.

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<>
>>> We would then have had an empty abstract class. So why not an 
>>> interface?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message