"Ralph Johnson" johnson@cs.uiuc.edu writes:
I suggest you make that change in all your programs and report back next year. In fact, I encourage lots of people to make that change. Then, when we have a debate in a year we can have testimonials like "I tried it and everything was fine" or "I tried it and it broke XXX". That would be the right time to make the change. Or not.
As an aside, having a public package universe can provide more input to these decisions. The idea is, packages include self tests, and you have a package universe listing the packages that you want to continue to support. Then, whenever you are considering a change, you can make it locally and then run all of the packages' self tests to see if anything broke.
There are a few aspects to this approach to keep in mind. One is that you need a way to associate tests and packages. Whereas Scala uses the filesystem for this [1], Squeak could use a registry object.
Second, you have to have a list of packages that you care about. A package universe works can itself be such a list. SqueakMap also have version tags that you can use, although for some reason these tags are not always up to date. Whatever you do, though, you have to have SOME kind of list of relevant packages. How to develope that list is a fascinating question.
-Lex
[1] From http://permalink.gmane.org/gmane.comp.lang.scala/2894 :
To register a self test, the package should include a file whose name is misc/sbaz-testall/tests/package-name, where package-name is the name of the package with a self test. The contents of the file should be a single line with the name of the object or class holding the self test.