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
