Phil Steitz a écrit : > Luc Maisonobe wrote: >> Sam Halliday a écrit : >> >>> I've had a quick look at the 2.0 API and the only changes I'd like to >>> request >>> are:- >>> >>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse >>> storage >>> implementation. Can be empty (for now). >>> >> >> I suppose these interfaces would extend Real{Matrix, Vector} ? >> >> >>> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, >>> Vector}. >>> Implement above interfaces. >>> >> >> I have no opinion on that. What do others think ? >> > +1 for "dethroning" ;) > > With the new interfaces, we could also drop the "Sparse" from the name - > i.e, "OpenMapRealMatrix" > > I am wondering now whether similar marking and "dethroning" should > happen on the dense side - i.e DenseReal{Matrix, Vector}, > BlockRealMatrix (currently DenseRealMatrix), ArrayRealMatrix (currently > RealMatrixImpl)?
+1. This is simple for DenseRealMatrix since it has been created after 1.2, but RealMatrixImpl may induce more problems to users. Should we copy an deprecate ? >> >>> - implementations should subclass the return type of some methods in the >>> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a >>> RealVector, >>> but could declare that it returns a RealVectorImpl. This will avoid >>> needless >>> user casts. In future APIs, this could be a powerful way to define the >>> return type of matrix-matrix computation when the storage classes are >>> known... e.g. declaring that you return a DiagonalMatrix. >> >> I didn't know changing the return type to a subtype was allowed when >> implementing an interface! This is for sure a good thing to do and could >> probably be used in many other places too. >> > +1 in general, but need to realize that when implemented, this changes > locks us in. In the specific cases mentioned above, this is a > no-brainer, but there are others (mostly in the decomp classes) where it > is not so obvious. > >> >>> - is it too late to define a Norm enum and take that as a parameter, >>> rather >>> than explicit methods for each Norm type? >>> >> >> There are many places where we use the same pattern outside of linear >> algebra. I'm reluctant to change this because if we extend the enum >> later, we may forget to add a new case in all implementations (somewhere >> in a switch statement), so we should add an exception for defensive >> programming. A method name enforced in an interface prevent such errors, >> you cannot compile your implementation if you forget a method. >> > Agree with Luc on this, but more from a Java style than maintenance > standpoint. We have tried in general to stay away from "behavior flags" > in method signatures up to now. > > Phil > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org