multiple classes with the same name, namespaces
craig at netjam.org
Sat May 27 09:02:18 UTC 2006
> > Spoon currently still has the old system dictionary, but I'd like to
> > remove it. I think we should just rewrite users of "Smalltalk at:"
> > (probably in some automated fashion, both in situ and during method
> > transfer).
> And how do you propose to do this?
It would proceed similarly to what happens when an author attempts to
compile some source that uses an overloaded class name. When we
encounter an occurrence of "Smalltalk at:", we can find all the classes
in the system which have the given name. We don't have to use
>>allSubclasses since we'll have a cache of all classes in the system
(recall my proposed replacement for the current system dictionary).
If there is more than one class with the given name, we can ask the
human to disambiguate, showing further information about the matching
classes (author, module, etc.). If one of the choices is in a "kernel"
module (as opposed to a third-party module), that could be the default.
I'll note here that I think "Smalltalk at:" is poor style in the first
> > The classes we can put in some cache collection that is known to the
> > compiler, but it need not be keyed. Then each class has complete
> > responsibility for its name, and we needn't worry about other
> > objects having out-of-sync notions of any class names.
> So, you want to find a class by sequential search, asking each class
> for its name?
Yes, because class names are dynamic. I don't think the time hit is a
big deal, either. I assume you do?
> Do you want to search the subclasses of Object, or ProtoObject? Or
> would you rather have a separate object to be this cache?
The latter (as I mentioned previously). And now that you mention
ProtoObject... :) Spoon has no need for ProtoObject; in particular,
Spoon's proxy class works with VM assistance and its superclass can be
anything. I intend to remove ProtoObject.
> If you have a separate object, how do you add objects to it when you
> load a module?
When you load a module, what you're actually doing is asking a new,
empty, local module to synchronize itself with a remote module that has
what you want (see Module>>synchronizeWith:). This effectively
synchronizes the two systems which host the modules, with regard to the
desired module content. During this synchronization, new classes which
are defined in the local system would be added to the class cache by the
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]
More information about the Squeak-dev