Jake Mannix a écrit : > On Thu, Oct 15, 2009 at 7:18 PM, Bill Barker <billwbar...@verizon.net>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. Luc > > -jake > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
