On Nov 30, 2006, at 13:06 , Lex Spoon wrote:
tim Rowledge tim@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.