commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Questions about the linear package
Date Fri, 16 Oct 2009 17:45:46 GMT
Jake Mannix a écrit :
> On Thu, Oct 15, 2009 at 7:18 PM, Bill Barker <>wrote:
>> I'm +1 on this (including being willing to help).  Like Luc, I don't
>> believe that there are very many people implementing custom versons of these
>> interfaces.
> Ok great, I feel a consensus building here, so I'm going to write up a JIRA
> ticket with a nice beefy patch implementing these ideas along with providing
> the AbstractRealVector which uses the newly added iterator() and
> nonDefaultIterator() abstract methods, in combination with the general
> map(UnaryFunction), map(BinaryFunction, RealVector),
> collect(UnaryCollector), collect(BinaryCollector, RealVector) abstractions,
> to provide base implementations for all the various mapXXX and mapXXXtoSelf,
> normXXX and distanceXXX methods so that subclasses can either stick with the
> default or do some perf-enhancing speedups of their own.
> I'll leave the huge plethora of methods alone for now, and we can decide
> later if there is some subset of them which we can feel comfortable breaking
> back-compat on by removing from the interface.
> I'm +1 to deprecate these methods in 2.x, but -1* on removing them from the
>> interface before 3.0.  There is a high expectation for commons projects that
>> you can upgrade to minor versions by just dropping in the new jar file.
> And to play the devil's advocate: how many users of commons-math have
> upgraded to 2.0 since it came out, and in that time, started using
> "mapCoshToSelf()" on their vectors? :)  In all practicality, there might not
> be a single person out there who would be affected by a 2.1 coming out with
> deprecation warnings, followed by 2.2 losing the more esoteric methods
> altogether...
> In principle I'm definitely behind the back-compat clause, but technically,
> if we're going with the route suggested by Luc that we add new methods to
> this interface, we *are* opening the possibility of someone having their own
> custom impl of RealVector linked against 2.0 which would flat out break when
> trying to drop in 2.1 with the new interface.
> But as I said - I'm new here, so I'll just leave methods already there in
> place, and whatever you guys want to do about deprecation/removal seems fine
> - the api/interface would be cleaner without all those methods, but
> providing an AbstractRealVector which lets you safely ignore them should
> make that uncleanness pretty ignorable.

I agree with Bill. Even if this sounds a bit too conservative, we won't
remove these methods before 3.0. When I asked if we were going to remove
them, what I had in mind was deprecating them as soon as possible to
warn users they will be removed later, but the removal will only occur
at a major release.


>   -jake

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

View raw message