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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
