Squeak and Namespaces
goran at krampe.se
Thu Nov 30 09:43:14 UTC 2006
> Hi G"oran,
> on Thu, 30 Nov 2006 09:33:01 +0100, you wrote:
>> There is AFAICT nothing really stopping us from putting some kind of
>> "imports" into the system later. But it has the following "problems":
>> 1. We loose the "single mode" that is a large part of the Smalltalk
>> In Squeak I can type an expression anywhere and just "do it". With
>> you suddenly get the inevitable question "In what context?".
> This is exactly the *explicit* situation of the automated language
> translator and the [tendentially] *implicit* situation of the human reader
> / listener, thank you G"oran for bringing this up!
Not sure what you mean though. :)
[SNIP of micro glossaries]
>> What is the consequence? Well, in *practice* this emulates my solution -
>> only type short names and it asks when there are choices.
> And preserve that during fileOut?
Yes, the fileouts (actually - the SOURCE - not just the fileout) always
contain the class names. And recall the the names of the classes are the
fully qualified names - just like the name of WAComponent is...
#WAComponent today. No difference whatsoever with how it works today.
The only differences are in how the code viewers/editors choose to render
and accept qualified names/short names.
> And cause conflicts (DNU's?) during
Nope. No conflicts, just like how WAComponent doesn't conflict with
anything today unless someone uses the exact same prefix and short name.
>> You hardly ever
>> look at the imports anymore - which is yet another evidence that you
>> typically *know* what you use/import.
> Except when you hunt for bugs where two methods of the same class (and on
> the same side) use different namespaces?
Waff? In Java?
>> Ok, I hate the way imports get into my face in Java. And people are more
>> or less only offering solutions based on very similar models. I really
>> would like for people to try to think "out of the box" here. And I am
>> referring to you Andreas - you already have enough insight. But others
>> might benefit from at least *contemplating* that namespaces:
>> - Don't *have* to be hierarchical.
>> - Don't *have* to use file/class/package level imports.
> - Don't *have* to be explicit.
Unsure what you mean with "explicit".
More information about the Squeak-dev