commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [math] 1.1 clirr report, backward compatibility
Date Sun, 12 Jun 2005 23:52:37 GMT

Simon Kitching wrote:
> So looking at possible solutions...
> 
> The current situation is:
>   interface Foo
>   class Impl implements Foo
> 
> Is it possible to do this?
>   interface ExtendedFoo implements Foo
>   class Impl implements ExtendedFoo
> 
> In this way, Foo doesn't change, but new code can pass objects around as
> ExtendedFoo in order to access the new functionality.
> 
> [NB: I'm not actually suggesting a literal use of the prefix Extended. A
> real, meaningful, name should be selected]
> 
> Alternatively how about this?
>   interface NewStuff
>   class Impl implements Foo, NewStuff

Indeed, all are possible solutions, as is
interface Foo2 extends Foo

Also, if you haven't read it, 
http://eclipse.org/eclipse/development/java-api-evolution.html is a 
*very* good read on this topic.

Stephen

---------------------------------------------------------------------
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