commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject Re: (MATH-608) Remove methods from RealMatrix Interface
Date Sun, 03 Jul 2011 02:16:18 GMT
Yes, I believe you would have a new tagging interface called
BandedSymmetric. Implementing both interfaces would probably open things to
many errors...

2011/7/2 Sébastien Brisard <sebastien.brisard@m4x.org>

> But if you have a method taking as an input a matrix which MUST be both
> symmetric and banded, you are bound to define a new interface.
> Am I wrong?
> Maybe the alternative you are thinking of is testing "instanceof
> SymmetricMatrix" and "instanceof BandedMatrix" in the implementation of the
> method, instead of specifying the required matrix in the declaration of the
> method?
>
> Le 02/07/11 21:18, Greg Sterijevski a écrit :
>
>> Not a stupid concern in my book. However there is a synchronization
>> mechanism in place. We are taking part in it right now. Whether the new
>> matrix implements both SymmetricMatrix and BandedMatrix or is a new
>> tagging
>> interface (SymmetricBanded) would determined in the list, after a bit of
>> back and forth.
>>
>> 2011/7/2 Sébastien Brisard<sebastien.brisard@m4x.**org<sebastien.brisard@m4x.org>
>> >
>>
>>  Marker interface seems to be a very elegant solution. I am just wondering
>>> about a potential issue. Let us assume we defined two interfaces, say
>>> SymmetricMatrix, and BandedMatrix. User A writes a matrix class which
>>> implements both interfaces. Meanwhile, user B implements an algorithm
>>> which
>>> requires a symmetric, banded matrix. Presummably, user B will define a
>>> new
>>> marker interface, which extends both SymmetricMatrix and BandedMatrix. So
>>> we
>>> have on the one hand
>>>
>>> class UserAMatrix implements SymmetricMatrix, BandedMatrix;
>>>
>>> and
>>>
>>> UserBAlgorithm.operate(****BandedSymmetricMatrix).
>>>
>>> One day, user A hears of the work of user B. The matrix he has
>>> implemented
>>> has just the required features (symmetric *and* banded). But it does not
>>> implement BandedSymmetricMatrix, so he cannot apply
>>> UserBAlgorithm.operate
>>> to an instance of UserAMatrix. There is always the possibility of
>>> creating a
>>> new class which extends UserAMatrix and implements BandedSymmetricMatrix,
>>> but that would obfuscate the hierarchy tree. Is this a problem? Is that a
>>> stupid remark?
>>>
>>> Sebastien
>>>
>>>
>>>
>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.org<http://apache.org>
>>> <dev-unsubscribe@**commons.apache.org<dev-unsubscribe@commons.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message