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