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)?
- 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
