Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of brenopr@terra.com.br
 designates 200.154.55.229 as permitted sender)
Received-SPF: pass (buvuma.terra.com.br: domain of terra.com.br designates
 200.154.55.139 as permitted sender) client-ip=200.154.55.139;
 envelope-from=brenopr@terra.com.br; helo=[10.1.1.2];
Message-ID: <42AD0D67.9020508@terra.com.br>
Date: Mon, 13 Jun 2005 01:36:55 -0300
From: Rodrigo di Lorenzo Lopes <brenopr@terra.com.br>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math] 1.1 clirr report, backward compatibility
References: <8a81b4af05061208137d6b5650@mail.gmail.com>
	 <42AC60C2.3030004@gmail.com>
 <42AC7305.3060407@btopenworld.com>	 <42AC94D2.3050304@gmail.com>
 <42ACB38F.9070901@btopenworld.com>
	 <8a81b4af05061216153e84f942@mail.gmail.com>
	 <1118618775.3798.5.camel@localhost.localdomain>
	 <42ACCAC5.3070804@btopenworld.com>
  <42ACEDA4.5010601@gmail.com>	 <1118630871.3798.49.camel@localhost.localdomain>
	<1118631215.3798.57.camel@localhost.localdomain> <42ACFC42.5000206@gmail.com>
In-Reply-To: <42ACFC42.5000206@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

So, only to put my opinion in vote terms:

+1 could break backward compatibility  in release 2.0 if necessary:

We must change the API. There are so many to improve. We cannot be 
plastered , specially now that commons math is still far from a stable 
API. But I agree with backward compatibility directions anyway.

+1 to create a most abstract interface like:

interface InterfaceFoo2 extends  InterfaceFoo1

The reasons I�ve already posted in last mail.;)


Mark Diggory wrote:

> Simon Kitching wrote:
>
>> On Mon, 2005-06-13 at 14:47 +1200, Simon Kitching wrote:
>>  
>>
>>> Hi Mark,
>>>
>>> In the example below, I would regard this change as being an
>>> incompatible change anyway. Code using the new API isn't compatible 
>>> with
>>> code implementing the old API because an exception can be thrown when
>>> invoking a normal-looking method. Maybe if the new method's javadoc
>>> explicitly states that "some implementations may not support this
>>> operation and will throw an exception" but even then it feels wrong to
>>> me.
>>>   
>>
> Well, its not elegant, the exception handling establishes that there 
> is a forwards compatibility issue with the third parties 
> implementation (which they would then have to correct). Ultimately, 
> either way the third party needs to make the modification, the Stub 
> just delays this fact. Which is better, break during compilation, or 
> break during runtime? This shows a downfall in the strategy, a break 
> during compilation is more likely to be caught by the third party 
> developers and an exception is more likely to be caught by the third 
> parties "users". It'd seem better if the incompatibility were caught 
> by the developers, so in this way my example sucks. The simplest case 
> ends up the best. Just modify the Interface directly (yes, on a Major 
> release version) and let the third party developers adapt, thats 
> software evolution.
>
>>> There are some cases where this pattern does work, though.
>>>
>>> Commons-digester declares Rule as an abstract class rather than an
>>> interface. This allowed the begin/body/end methods to be enhanced with
>>> additional parameters, with the new methods delegating back to the old
>>> ones by default. This pattern is also described in the eclipse doc
>>> referenced by Stephen below. There isn't any interface involved, 
>>> though:
>>> an abstract class is used *in place of* an interface.
>>>
>>> In commons-digester 2.x (nowhere near release yet), Action is an
>>> interface whose javadoc declares explicitly that it may change in minor
>>> releases, and that users should subclass AbstractAction instead:
>>> http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/ 
>>>
>>>
>>>   
>>
>>
>> I should note that the reason that digester2 adopted the "interface +
>> abstract implementation" rather than the digester1 "abstract class
>> instead of interface" approach was that people pointed out:
>> * interfaces are useful for generating dynamic proxies at runtime.
>> * mock objects for unit testing are easier done on interfaces
>>  
>>
>> Neither of these have problems associated with evolving the interface;
>> the dynamic problem of course isn't relevant and the unit tests can
>> assume to be only internal to the project and can be updated to match
>> the new release.
>>
>> And where 99% of user code is simply *using* the API instead of
>> *implementing* the API, they can deal with the nice and traditional
>> interface. Only implementers of the API really need to care about the
>> existence of the abstract class.
>>
>>  
>>
> Not only this but that 1% actually implementing the API is more than 
> likely going to be lurking on your developer list and contributing to 
> its development ;-)
>
> IMHO, our current userbase is simply just using the API at this point 
> and will tolerate interface changes if it improves the API, it would 
> be an interesting poll to see if anyone actually implemented their own 
> Matrix classes on our interfaces and I'd be extremely surprised if it 
> had.
>
> -Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


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