"Ralph Johnson" <johnson at 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.