Phil, "Fortunately for users, maybe less fortunately for developers, we can't really "evolve" our API rapidly .... This is why we favor abstract classes over interfaces."
Just so that I am sure I understand, let me restate the objection to an interface. An interface approach is more likely to be used broadly, so any changes which might be made would have a disproportionately large impact. Is this correct? Isn't this a bit of a punt? On the surface the user gets a guarantee, but the guarantee is a deadend. If we decide a different approach is warranted, the object is deprecated and ditched at some point. More importantly, if it is a successful interface isn't that a good thing? If it makes its way into a lot of other code, then I doubt we will need to make many changes. Also, I foresee a two track evolution of features. The interface defines the basic, most limited set of functionality. Everything else is throw into abstract and concrete implementations. When a functionality seems to exist in most derived classes, then the debate should commence about its inclusion in the regression interface. The evolution would most likely be new features in, as opposed to current features cut out. There would be a lag of probably a year in moving a new feature up the inheritance structure to the interface. Maybe your experience is different. I could be wrong about user demands... Thanks, -Greg
