Hi Gilles, Gilles Sadowski wrote:
> Hi. > >> We have been talking about moving away from interfaces as the >> preferred way to support people plugging in alternative >> implementations because they have in several places gotten "behind" >> due to the fact that adding anything to them breaks compatibility. >> We should probably continue that discussion in a different thread. > > [This is the different thread.] > > From comments that were posted to the other thread, I gather the main > trend that, because some interfaces needed an upgrade, the "interface" > design tool is becoming "evil". Did I get this right? > > I guess that you refer to "RandomData" and "RandomDataImpl". This is > indeed the typical example of abusing the "interface" tool. When only one > implementation is meaningful, an "interface" need not be defined. No. It is about adding something to the interface, just like Phil said. If you add a method to an abstract class, the dervied ones are still binary compatible, the same does not apply for interfaces. We had discussions in *length* about this and I am not interested in starting over again. > The "interface" is not the way (preferred or not) to support alternative > implementations. As was already said, this is done with (abstract or not) > classes which an alternative implementation can inherit from. > Rather, the (Java) "interface" is supposed to represent the abstraction > (from the "real" world object) of everything that is needed to interact > with that object (i.e. its interface). It makes it possible to treat > different objects on a equal footing (from the caller's point-of-view). > But you all know that... > > So what's the problem? Is it the binary compatibility, again? This is a > configuration management issue. When the compatibility is broken, you > change the major version number and/or the base package name. That was > settled, or not? The point is that an interface should not be changed for a long time. Otherwise every new release is a major one. > It would be a pity to sacrifice a tool aimed at improving the design > because of such considerations as keeping backward compatibility with > versions that nobody here is going to support. It's a pity for the user, because he will *never* be able to use the next version as drop in. > If some user is happy with version "M.m", he can use it forever. If he > wants to use a newer version "N.n", he should not expect it to be > compatible. It does not have to be! Non-compatible modifications are not > performed out of some urge for change but stem from the desire to get a > better product, bits by bits. If that were true, you would currently have 10 different commons-lang, 10 different commons-collections and so on in your classpath. > Yes, it's not easy to get the interfaces right; so what? If you find that > you can improve the design, you do it and bump the major verion number. > As someone pointed out, it's not as if we'll run out of numbers. And people will stop using it, because they are annoyed when they are depending in the end on n different versions of math, simply because of transitive dependencies. > Part of the real problem (as shown by the amazing amount of done and > undone work for 2.2) is that you (collectively) want to do too many things > at the same time (lots of changes *and* few releases). To be clear, the > problem is not the "lots of changes" part (which you would like to "solve" > by vetoing future compatibility-breaking improvements). Note that the > following is not a criticism of CM (which has many features etc.) but some > of the code that I've seen (in the parts which I've more closely looked > at) do not make me think that it is mature enough that one can say "That's > it!" and stick with the design forever. > Again, all this (e.g. removing duplicate code and refactoring the design) > can be considered unimportant and swept under the carpet but IMO *any* > cleanup is good as it will contribute to the overall robustness and > maintainability. > Half-baked design will continue to itch. Half-baked upgrade strategies also. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
