Hi. > On 6 December 2010 22:21, Gilles Sadowski <[email protected]> > wrote: > >> >> > - * @deprecated in 2.2 (to be removed in 3.0). Please use > >> >> > - * {...@link #map(UnivariateRealFunction)} directly with > >> >> > - * the function classes in package > >> >> > - * {...@link org.apache.commons.math.analysis.function}. > >> >> > + * @deprecated in 2.2 (to be removed in 3.0). > >> >> > >> >> Why not leave the reference to #map(UnivariateRealFunction) ? > >> > > >> > Because the package "function" does not exist in MATH_2_X. > >> > >> I know that, but #map(UnivariateRealFunction) does exist (in the same > >> source file). > >> > >> It was only the reference to the package name that was wrong. > >> > >> If the replacement for the deprecated methods is not > >> #map(UnivariateRealFunction), then whatever is the replacement should > >> be specified in the Javadoc. > > > > The replacement is the method "map" (which exists) together with the > > appropriate function (which doesn't, unless someone wants to backport the > > "function" package). > > There are several implementations of UnivariateRealFunction, e.g. > PolynomialFunctionLagrangeForm. > > Are these not suitable as parameters to the map method?
They are, but they do not provide a replacement for the deprecated methods, which is the point of a more detailed deprecation message. > > I think that we agreed with Phil that when the replacement doesn't exist, it > > is sufficient to warn the users with a terse deprecation message. > > I don't think it is right to leave the user totally in the dark as to > how to resolve the deprecation warnings. There is no possible resolution in 2.2. The deprecation warning says: "You will have to modify that code when upgrading to 3.0". Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
