multiple classes with the same name, namespaces

Craig Latta craig at
Sat May 27 09:02:18 UTC 2006

Hi Ralph--

 > > 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 
local module.



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

More information about the Squeak-dev mailing list