"Ken G. Brown" kbrown@tnc.ab.ca wrote:
With respect to Craig's 'Flow', I have been thinking about the inertia caused by the perceived need to make major system changes backward compatible.
The principle Ken and others are stating is great. My suggestion is simply that we should focus on changes that really are useful. We should not just move things around because we think it looks nicer. Lots of people are building on top of Squeak, and we shouldn't cause them grief unless there is actually a reason for it. And we most certainly should not break our own code all the time. That's no way to move forward.
As an example, renaming of classes and methods is a poor bargain. Yes, arguably the new names are better. (Though arguably, in many cases the old names were better, too!!) This is a minor change. This is a change that no one will regret having seen when they are old. But, it is a change that very easily breaks lots of code. Why do it?
And if we must do it for some good reason, please let's have a grace period, and not remove the old name until -- at *least* -- the maintained code on SqueakMap has been moved over. Don't just pull the rug out one day.
Overall, while we must break a few eggs as time goes on, we don't need to jump around and stomp on the whole batch.
Lex