On Nov 30, 2006, at 13:06 , Lex Spoon wrote:

> tim Rowledge <tim at rowledge.org> writes:
>> Forgive me if I'm being hopelessly naive here (remember, none of my
>> degrees are in CS ) but isn't namespaces something that has been
>> solved before? I mean, it's not exactly a new issue is it? Isn't
>> there a standard somewhere for dealing with them?
>
> It is an old issue that has seen a lot of research.  I don't think
> there is a consensus on a good solution, though.  Keep in mind that
> this stuff is related to the ongoing work on components, an area that
> seems to be nowhere near mined out.
>
> Practically, a Java-like solution seems pretty good.

Actually, IMHO import lists like in Java or Python do not fit  
Smalltalk at all. Sure, people want to use unqualified names in their  
code. But in those file-centric environments, you know exactly where  
to look to identify which local name refers to which global name -  
you scroll up a few pages to the import list. Also, these imports  
always travel with the code using them, because it's in the same file.

Not so in Smalltalk. As has been noted elsewhere, the compilation  
unit is a method in a class. Consequently, you need either fully  
qualified names, or have class-based imports. We already have a way  
to express the latter (class pools [*]), and we may like to have a  
way for the former. That's all.

- Bert -

[*] Try this on the class side of some class:

initialize
	self ensureClassPool.
	classPool at: #Button put: SimpleButtonMorph

 From now on, you can refer to SimpleButtonMorph simply by Button. To  
share this "import", simply put the code into a SharedPool subclass  
and list that in the poolDictionaries of your class.