Hi Chris--
...it will help a lot to have completely unconstrained class names...
I don't understand this. What do hard-references to classes in code bind to then?
That machinery is unchanged. The class objects themselves are mentioned in the literal frames of the methods in which they appear. The execution machinery doesn't care what their names are, just their object identities ("Name And Identity Are Distinct"). Any tool that displays source code can be smart about methods with literal frames that refer to classes with names shared by other classes (phew).
Such a tool can render the *source code* of such a method to cue the reader that such a class does not have a unique name. For example, the tool could use a hyperlink, which the reader could follow to find out more about the particular class object used by a method.
For example, two totally different Person classes are loaded and one code says:
myPerson := Person new
and other:
someOtherKindOfPerson := Person new
Ah, is there a conflict-checking operation that dynamically renames one of them?
No, they both get to keep their identical names. That is to say, both class objects have #Foo in their "name" slot (said slot currently defined by class Class). So, we've got two class objects; for the sake of discussion, let's say that one of them has name #Foo and identity hash 7777, and the other has name #Foo and identity hash 8888. (Note that Spoon actually uses metaclass UUID slots to track the identity of each class/metaclass pair.)
Now, for the first expression you mentioned, there is a corresponding method literal that refers to the class with identity hash 7777. For the second expression, there is a corresponding method literal that refers to the class with identity hash 8888. There is no effect on the source code (both expressions simply refer to "Person"), which makes sense since we can transfer methods between systems without using source code or compiling anything. When transferring behavior, source code is merely an annotation for the benefit of human readers (particularly given the fact that we can decompile methods at will).
The only compilation that need occur is when authors accept methods after editing. The browser can easily detect when an author attempts to compile some source which invokes a name used by multiple classes, and prompt for disambiguation. The system could, for example, provide a list of the class categories in which the "Person" classes appear.
In effect, each class in the system has its own namespace, since all class names are completely unconstrained all the time in all locations (i.e., "universally", which really just recapitulates the "universal" in "UUID" :). It will still be useful to put classes into named groups, for the purposes of organizing them, but I don't consider such groups to be namespaces. For one thing, within any such group you can have any number of classes with the same name. You could give every class in the system the same name if you really wanted to. :)
This scheme doesn't really work if behavior moves between systems by means of source code in files (fileouts), as we've done previously.
I hope that helps, thanks for asking!
-C
spoon@lists.squeakfoundation.org