commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <>
Subject Re: [math] Questions about the linear package
Date Thu, 15 Oct 2009 16:30:03 GMT
On Thu, Oct 15, 2009 at 1:55 AM, <> wrote:

> ----- "Jake Mannix" <> a écrit :
> You are both right.
> I was mainly refering to removing methods as this affects not only
> implementations but mainly user code.
> Adding new methods to interfaces is an incompatible change in the sens that
> existing implementations need to add this. However, I would be pragmatic
> here. The odds are very low that someone dared to add his own implementation
> of such huge interfaces, they are mainly for our own use and they are really
> new as they were created for 2.0. In addition, we would provide a default
> implementation for these new methods, so if someone did really create a
> class that implements RealVector, he would simply have to say it extends
> AbstractRealVector instead. So there is a clear gain to accept this kind of
> incompatible change as soon as 2.1.
> What do other people think about this ?

+1 big time from me - this makes my job of a patch much easier, and I think
it makes things much cleaner.  I'll convert my patch (not posted yet,
because there are no tests yet) to this style so people can see what it
looks like in this format.

Perhaps we should also deprecate the gazillion maptXxx and ebeXxx methods,
> I'm not sure.

We could keep them implemented in the base AbstractRealVector, but deprecate
them from the interface, and could then we remove them from the interface in
2.1, noting to people that casting to AbstractRealVector will allow you to
continue to use them for clients who need an easy upgrade path and don't
want to migrate to using map(Function f).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message