Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of gsterijevski@gmail.com
 designates 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E0F6818.4010203@m4x.org>
References: <4E0F6818.4010203@m4x.org>
Date: Sat, 2 Jul 2011 14:18:12 -0500
Message-ID: <BANLkTikmbbwLGjbdFXh-nZRqkBEFTLK__A@mail.gmail.com>
Subject: Re: (MATH-608) Remove methods from RealMatrix Interface
From: Greg Sterijevski <gsterijevski@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=0016e64ec278d2f7a504a71afe2d

--0016e64ec278d2f7a504a71afe2d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=E9bastien Brisard <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 whi=
ch
> requires a symmetric, banded matrix. Presummably, user B will define a ne=
w
> 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 implemente=
d
> has just the required features (symmetric *and* banded). But it does not
> implement BandedSymmetricMatrix, so he cannot apply UserBAlgorithm.operat=
e
> to an instance of UserAMatrix. There is always the possibility of creatin=
g 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.**apache.org<dev-unsubscr=
ibe@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--0016e64ec278d2f7a504a71afe2d--