commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <>
Subject Re: (MATH-608) Remove methods from RealMatrix Interface
Date Sat, 02 Jul 2011 19:18:12 GMT
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 <>

> 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.**<>
> For additional commands, e-mail:

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