A little namespace "proposal"

Roel Wuyts Roel.Wuyts at ulb.ac.be
Tue Apr 6 16:10:46 UTC 2004


Okay, have to run now. Briefly some comments.

On 06 Apr 2004, at 18:40, goran.krampe at bluefish.se wrote:

> Hi Roel and all!
>
[snip]

>>>
>>
>> I would never want to see Delay, and always Kernel::Delay. In your
>> proposal, things get ambiguous if one adds another namespace that
>> introduces Delay later on. To make sure I am clear, I'll give a little
>> scenario:
>> (1) I add a class Roel::Classification, so a namespace Roel exists, 
>> and
>> my class in it.
>> (2) I add a class Roel::Item, that has a method foo that somewhere
>> says: 'Classification new'.
>> 	We all know what this means: a Roel::Classification new. So in your
>> proposal, the source reads as above, in mine it would read
>> 'Roel::Classification new'.
>> 	No problems yet.
>> (3) I load another package that has a class Alex::Classification (or I
>> add it myself, doesn't matter).
>> (4) I open a browser on my class Roel::Item, and have a look at the
>> source code. Now it is not so clear anymore which classification is
>> meant without the prefix.

yes, I thought about that as well. Fine by me, although I still prefer 
mine...

>
> That is why I tried to explain that as soon as Alex::Classification
> enters the image your code in Roel::Item>>foo will suddenly read like
> "Roel::Classification new". Hmmm, didn't I write that? Perhaps not. 
> That
> was at least the intention!
>
> The idea is to allow the short form if there is no ambiguity in the
> image. And expand it to the qualified form if there suddenly is. So 
> this
> means that source will "change" under our feet. :) But hey - this is
> Squeak and we can do that, can't we?
>
> It is that trick that makes it so beautiful IMHO. Because it 
> annihilates
> the use of imports - since most available classes will be uniquely 
> named
> in themselves. :)
>
>> So I am afraid that omitting the namespace is not a good thing with
>> respect to evolution and change. Adding the prefix makes it sound
>> again. And because needs to do the same checks, it does not even 
>> change
>> anything for the developer.
>
> I am not sure you understood that the class reference is always
> qualified "under the hood" but we choose to "render it" like "Delay" 
> (if
> there is no ambiguity) and automatically turn it into "Kernel::Delay" 
> if
> there suddenly is disambiguity.

Yes, got that. But still prefer an explicit rendering :-)

>
>> Note that this also means that it is more likely to notice spelling
>> mistakes with namespaces, since you've much more chance to see them.
>> When the lookup finds them in the misnamed namespace, you probably
>> won't see a mistake until much later, which can be quite annoying.
>
> The problem here is that having all class references in the source 
> being
> fully qualified will get messy to read. And then people will start
> yelling for imports and hey, there we go down the Java path...

Yuk, can't have that :-) Good poiont; have to think about it...

>
>>> Note to Andreas: The signals and code here is of course up for
>>> discussion, I really don't care as long as the end result is the 
>>> same.
>>> :)
>>>
>>> 2. If you type in an explicit reference "Kernel::Delay" then the
>>> Compiler (or whatever) first checks for the Namespace "Kernel" and if
>>> that exists looks for the name "Delay" in it. If it isn't resolved 
>>> then
>>> an Exception is signaled and the Browser should look through all 
>>> other
>>> Namespaces for "Delay" and if found - ask if it should be corrected. 
>>> If
>>> there is only one Delay in the system to find, then it can be 
>>> corrected
>>> to "Delay", otherwise it will be corrected to the fully qualified 
>>> form.
>>>
>>> The net effect of the above is that Squeak code as it stands today
>>> still
>>> works fine after a recompile. I think. :).
>>
>> Yes, I also think. Even in "my version".
>>
>>> Note also how this eliminates
>>> the needs for imports, the short form is usable in two scenarios:
>>> 	1. The name referenced is in the local namespace.
>>> 	2. There is only one such name in all the other Namespaces.
>>>
>>> This will also encourage us to to still have globally unique names in
>>> our packages which is a GOOD thing because no matter how cool
>>> namespaces
>>> we have - it all ends up in our heads - and our heads is just one big
>>> namespace. If many namespaces have "Delay" entries, it will still 
>>> mess
>>> with our heads. See below for a little "feature" that still makes it
>>> possible to have duplicate names without "disturbing others".
>>>
>>>
>>> - When a new class "SqueakMap::Delay" is created the tools should 
>>> warn
>>> me that there already is a class called that in another Namespace and
>>> that it is generally better if the classes don't conflict by name
>>> because of the way resolving works. Sure, currently (before we get a
>>> superserver somewhere that can do lookups globally) this only checks
>>> against my current image but should still be useful.
>>>
>>> I then have a choice:
>>> 	1. Keep the name Delay and thus causing people with my code and the
>>> Kernel code in their image to be forced to choose which Delay they 
>>> mean
>>> every time they only write "Delay" instead of a fully qualified name.
>>> 	2. Rename it to MapUpdateDelay and be fine, that might very well be 
>>> a
>>> more precise name.
>>> 	3. Keep the name Delay but mark the name in the namespace as "shy".
>>> All
>>> names in all namespaces are by default used when trying to resolve a
>>> non-qualified name (as the resolving algorithm above showed - this is
>>> at
>>> the heart of the "optimism") and marking it as "shy" merely means 
>>> that
>>> when someone writes "Delay" the entry "SqueakMap::Delay" will not be
>>> presented as a choice. It doesn't mean anything else - for example,
>>> typing "SqueakMap::Delay" works just fine regardless if it is "shy" 
>>> or
>>> not.
>>
>> No, I don't like the last option at all. 1 and 2 leave the
>> responsibility in hands of the developer, which I like for handling
>> this kind of conflict. Option 3 is more complicated, you'll have
>> kind-of invisible stuff going on, you need to declare the shy-ness 
>> when
>> you add the class (since you don't create namespaces explicitly), etc.
>
> Yeah. Tell you what - we can skip it to start with and then if we never
> feel the need for it then you were right. :)
>
> regards, Göran
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Board Member of the European Smalltalk User Group: www.esug.org




More information about the Squeak-dev mailing list