commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [math] understanding BigMatrixImpl.TOO_SMALL field
Date Mon, 14 Jan 2008 05:39:11 GMT
On Jan 13, 2008 11:30 AM, sebb <sebbaz@gmail.com> wrote:
> On 12/01/2008, Phil Steitz <phil.steitz@gmail.com> wrote:
> > On Jan 12, 2008 3:45 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > > On 1/12/08, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
> > > > One comment about this change: this would break compatibility with
> > > > version 1.1 and the clirr plugin flags this as an error.
> > > <snip/>
> > >
>
> Seems to me that clirr compatibility should not be at the expense of
> bug-free code.
>
> > > That was my initial reaction as well when I read your first note
> > > (below). In general, we try to avoid incompatible changes (there are
> > > specific cases where we can attempt to push for exceptions, such as
> > > blatant bugs and/or v0.x releases).
> > >
> > > About the clirr errors you mention in the following paragraph, I
> > > suspect they will come up for discussion at the next release unless
> > > they are addressed or its a major release etc.
> > >
> > Yes.  We need to fix these things somehow.  The decision to make these
> > fields protected in 1.0 was unfortunate, but we need to find a way to
> > maintain compatibility while we deprecate things.  Sorry, I think this
> > was my mistake.  I will look into how to fix the problems in the stats
> > package.  IIRC, the BigMatrix.TOO_SMALL issue came up when we were
> > cutting 1.1 and we concluded then that there was no way to fix it
> > without breaking compatibility, which is why it is still there.  Might
> > be best to deprecate, so we can then make it both private and final in
> > 2.0.
> >
>
> Making the field final will prevent any bugs associated with changes
> to the value.
>
> This will obviously cause a clirr error, but it seems to me that any
> code that relies on being able to change the field is already in
> error, and therefore the clirr error should be overridden in this
> case.
>

I agree with the sentiment here, but don't like the idea of
incompatible change in a point release, so would prefer deprecate as
part of public API and then fix.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message