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. -jake
