On Wed, Mar 30, 2011 at 10:05:42AM -0700, Phil Steitz wrote: > We are mixing two things in this thread - how much we care about > backward compatibility and how and when to use interfaces. > > I think we need to settle both topics. I have stated my view, which > is really just to standard Commons policy, on the backward > compatibility issue. Based on many years experience using, > developing and maintaining libraries here and elsewhere, I agree > with others who have stated that constant incompatible change makes > a library almost worthless for use across a wide range of > applications. Something just used inside one application or > relatively small development group can be constantly refactored and > productively used; but broadly reusable components need to have > stable APIs. Incompatible changes have to be well-documented and > introduced in major releases that are relatively few and far > between. That is essentially how we have operated in Commons for > 10+ years now and it is the reason that some suggest that when we do > a major API refactoring of a component we change the package name > and even the component name. > > I don't buy the argument that we really *need* to keep making > incompatible API changes in [math] because there are features or > bugs that can't be added in compatible ways.
Who gave this argument? I argue that changes are necessary to straighten the design. > I have seen only a > tiny handful of these - just one in 2.2. Luc mentions SVD as a > frustrating problem for us. The bugs have nothing to do with the > API definition, unless I am missing something basic. What I argue has nothing to do with fixing bugs, although bugs can be discovered more easily when the design is consistent. > We have > numerical problems. We need to solve them. Gilles is right that we > have limited resources. I would much rather that these resources be > focused on solving the numerical and algorithmic problems involved > in delivering robust and stable mathematical software than endless > arguments about how to refactor the API. As a user, I would be much > happier with a stable API with a few warts that provides > well-documented, well-tested (because lots of users are using the > *same* core impl) mathematics than a beautiful but unstable API with > buggy implementation code. When the API has become beautiful, it will also be more stable. A consistent design is easier to document and test. Users cannot require that developers spend a single minute more on maintenance just to save their own time once in while. [Unless they pay them.] Both parties (users and developers) should equally share the burden. And, again, this only temporary; and indeed, it would have been more productive to do the changes and be done with it rather than argue endlessly. > Regarding interfaces, I think we are starting to focus on the right > question. I think we agree that use of interfaces just to separate > interface from implementation in support of the strategy pattern is, > let's just say "deprecated." When we started [math] back in 2003, > that was not considered bad design. We went overboard with it, > though, and ran into the problems we have been discussing on this > thread around extensibility. Most of the bad designs came from my > contributions, so I have to apologize for putting us into this position. You do not have to apologize. Trends change, and what was seen as good rules in textbook codes (e.g. checked exceptions) are challenged by the accumulated experience in programming projects. If we want CM to be an example to be followed, its code cannot stay as it was 8 years ago. > To allow multiple implementations of a fully defined interface, we > seem to have learned in Commons that abstract classes work better. > I am fine with that principle and will volunteer to start first > suggesting and discussing changes individually and then making > them. I already started this with RandomData/RandomDataImpl. We > can continue discussion on that thread about whether we even need an > abstract class in that case. > > Other use for interfaces are to > a) designate behaviors for implementation units that can be > "plugged in" to algorithms (where the interface defines only some of > the behaviors of the class - as in the multiple inheritance > example). An example of this is the RandomGenerator interface, > which encapsulates the behavior of a low-level source of random data. > b) encapsulate abstract data types, e.g. Field. > > I think we need to keep at least these interfaces, but we should > think long and hard about exactly what they should contain. Here > again, I think we need to look at each example individually. > Examples like RealMatrix could be argued to be good "b)" examples or > restrictive handcuffs that should be eliminated. I think we need to > be very careful with these decisions so that we can aim to really > stabilize the API in 3.0. I honestly do not think that is an > unrealistic expectation. I think that each specific issue should go to its own thread ;-) Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
