commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Interface vs class
Date Tue, 04 Nov 2008 21:25:19 GMT
Jörg Schaible schrieb:
> Hi,
> Ralph Goers wrote:
>> I believe this is the only discussion on 2.0 I've seen on the
>> dev list.
>> I went and scanned the archives a while ago. Rereading this thread I
>> don't really see a decision to use an Abstract class.  I'm not sure I
>> understand the discussion about which is more extendable. Yes, an
>> abstract class means you can provide a dummy implementation,
>> but this is
>> only of value if there are implementations of that extend it
>> outside the
>> project. I also tend to believe that thinking that you are somehow
>> better off with the abstract class is a fallacy. In many cases the
>> method you will be provide will either do nothing useful or will be
>> inappropriate for the "real" implementation. In both cases the
>> implementation class will still have to be modified to provide an
>> appropriate implementation of the new method. But worse, you
>> won't get
>> an indication that things are "broken" because the method
>> will be there.
>> If you were using an interface the problem would be apparent at load
>> time and the implementation would have to change to be
>> compatible with
>> the new release.
>> BTW - there is no reason you can't have an interface and an abstract
>> base class. 
> IMHO we should define what we want to reach. Adding a method to an interface does not
break *binary* compatibility of existing code. The method is simply not called. However, a
client will have to implement the new method, if CConf is a compile time dependency *and*
he uses an implementation not delivered by CConf. Maybe it is the best approach to have an
abstract base class and the interface. We have to tell our users, that they should extend
from the abstract class if they want to ensure backward compatibility for own implementations
of the Configuration interface. Point is, that it *is* only an advice/recommendation and something
like clirr will always report a violation in compatibility. Hoiwever, it is our desicion how
we should proceed.
> - Jörg
I 'd be happy to do it this way, but I am skeptical whether such a 
policy can actually be established. You know how hard it is to convince 
people to vote +1 for a release. If clirr claims that there is a binary 
incompatible change, chances a pretty good that you get a veto.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message