Return-Path: 
 <dev-return-106431-apmail-commons-dev-archive=commons.apache.org@commons.apache.org>
Delivered-To: apmail-commons-dev-archive@www.apache.org
Received: (qmail 32859 invoked from network); 14 Jan 2008 05:39:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 14 Jan 2008 05:39:47 -0000
Received: (qmail 98580 invoked by uid 500); 14 Jan 2008 05:39:35 -0000
Delivered-To: apmail-commons-dev-archive@commons.apache.org
Received: (qmail 98504 invoked by uid 500); 14 Jan 2008 05:39:35 -0000
Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@commons.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@commons.apache.org>
List-Post: <mailto:dev@commons.apache.org>
List-Id: <dev.commons.apache.org>
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Delivered-To: mailing list dev@commons.apache.org
Received: (qmail 98495 invoked by uid 99); 14 Jan 2008 05:39:35 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Jan 2008 21:39:35 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 72.14.220.154 as permitted sender)
Received: from [72.14.220.154] (HELO fg-out-1718.google.com) (72.14.220.154)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jan 2008 05:39:11 +0000
Received: by fg-out-1718.google.com with SMTP id 22so2378919fge.24
        for <dev@commons.apache.org>; Sun, 13 Jan 2008 21:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        bh=AIiku5ecFMrCBydxBa3x850Zq12SanOJN1z0G/0H+Ro=;
        b=sISmHp8MN6XNarhWd4C94zLHp9d8ywtLZxl9S2dC+gAiQBH0ZLS8gL0q3cw/xa1z0/2vz/e91W3TrVYEyDCHAkRa0SPOEEUKEi1YbFWTGap8iociX9RpRezL6wkXN4bHMDQqp1tN0H2kE1gf2f+osJseDF+unAAeyiGm331rF8Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=V+wlKCrdYcqAXmEMcIGp7TsHsGZuShOgjwC/PmSNbq2gsbzMSCZy7hJGCMXirDOwdwixVsaODEGONs3gCGy2XZAKTUGn2HjNoplCVDib0lnOR2QpZWmhXtOtj89sof1ssmrMuFvXgKzTjrB//ELZ+WZZ+Helg6ERL3AQWw4sadI=
Received: by 10.78.177.3 with SMTP id z3mr6688146hue.51.1200289151897;
        Sun, 13 Jan 2008 21:39:11 -0800 (PST)
Received: by 10.78.130.13 with HTTP; Sun, 13 Jan 2008 21:39:11 -0800 (PST)
Message-ID: <8a81b4af0801132139u366794e3l5e2e1d318f096a8@mail.gmail.com>
Date: Sun, 13 Jan 2008 22:39:11 -0700
From: "Phil Steitz" <phil.steitz@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [math] understanding BigMatrixImpl.TOO_SMALL field
In-Reply-To: <25aac9fc0801131030v41acbe60h455048c02abfec35@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47892A40.9010309@free.fr> <478935F1.8020504@free.fr>
	 <ce1f2ea80801121445x2b540fe5v183b1709bf384f48@mail.gmail.com>
	 <8a81b4af0801121549he5f1cc8j592a56198d05d934@mail.gmail.com>
	 <25aac9fc0801131030v41acbe60h455048c02abfec35@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

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