multiple classes with the same name
craig at netjam.org
Thu May 25 05:08:28 UTC 2006
> > ...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!
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]
More information about the Squeak-dev