A little namespace "proposal"
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!
>> 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
>> (1) I add a class Roel::Classification, so a namespace Roel exists,
>> 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
> 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.
> 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
> 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
> the use of imports - since most available classes will be uniquely
> 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
>> 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"
> there is no ambiguity) and automatically turn it into "Kernel::Delay"
> 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
> 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
>>> 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
>>> an Exception is signaled and the Browser should look through all
>>> Namespaces for "Delay" and if found - ask if it should be corrected.
>>> there is only one Delay in the system to find, then it can be
>>> to "Delay", otherwise it will be corrected to the fully qualified
>>> The net effect of the above is that Squeak code as it stands today
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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
>>> more precise name.
>>> 3. Keep the name Delay but mark the name in the namespace as "shy".
>>> names in all namespaces are by default used when trying to resolve a
>>> non-qualified name (as the resolving algorithm above showed - this is
>>> the heart of the "optimism") and marking it as "shy" merely means
>>> 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"
>> 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
>> 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 at ulb.ac.be Université Libre de
Board Member of the European Smalltalk User Group: www.esug.org
More information about the Squeak-dev