multiple classes with the same name

Craig Latta craig at
Thu May 25 05:08:28 UTC 2006

Hi Chris--

 > > 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!


Craig Latta
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]

More information about the Squeak-dev mailing list