commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo di Lorenzo Lopes <bren...@terra.com.br>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Mon, 13 Jun 2005 04:36:55 GMT
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


Mime
View raw message