Hi!

Peter van Rooijen <peter at vanrooijen.com> wrote:
> goran.krampe at bluefish.se wrote:
> > Peter van Rooijen <peter at vanrooijen.com> wrote:
> > 
> >>1) How to treat the already unique set of class names in the images as 
> >>they are, without namespaces?
> > 
> > I think that many of the classes in the current Basic image should still
> > be in Smalltalk - the root space you talk about.
> 
> Yes and no. I talked about "the root namespace", but I did not call it 
> Smalltalk. I agree with you inasfar that expressions like Smalltalk at: 
> #Set should still work. Whether the value of the name #Smalltalk in code 
> in the root namespace should be the root namespace itself is a question 
> I didn't address.

Hmmm. How would otherwise the expression "Smalltak at: #Set" work? :)

> I believe it doesn't matter as long as the Smalltalk 
> at: forms still work as expected and the other calls to Smalltalk keep 
> having the expected effect, so that old code is not hurt by having 
> namespaces. The joys of encapsulation through message sending :-).
> 
> > Not *all* though - we still have a lot of stuff in the Basic image that
> > really should be separate packages and thus probably have their own
> > namespace, or at least not be in Smalltalk.
> 
> Yes, I basically agree with that. Since all the class names currently 
> are already unique, they *could* all be in the same namespace without 
> causing problems. But there are undoubtedly many names that have been 
> disambiguated artificially (with prefixes or by using synonyms), and 
> they could benefit from being in another namespace. This can be done in 
> steps/phases, at moments of convenience.

Also - I think that some "areas of interest" currently in Basic *could*
benefit from having a Namespace of its own. Morphic is one of those
areas. I am not sure - just saying it *could* benefit.

> By the way, I have been talking about the "root namespace" (because I 
> assumed it would sound familiar), but at the same time I have advocated 
> not having a namespace *hierarchy*, but one root namespace and many 
> non-root namespaces. Therefore, the adjective "root" is not really 
> intention-revealing.
>
> I would suggest using this terminolgy: there is one "system namespace", 
> and then there are many "user namespaces". This is also correctly 
> suggestive of intention as using a namespace implies a responsibility to 
> avoid duplicate short names, and this must be done by the humans who are 
> the users of the Squeak programming system.

Mmmm, possibly. Though "user namespace" implies a single user IMHO, not
sure I like that. Though I don't have a good alternative except simply
"namespace". :) What is the current Smalltalk SystemDictionary "called"?
"Globals", right? That is still a good name I think.

So I would advocate:

- "the global namespace" = Smalltalk. Just as today. No difference.
Holds the other namespaces.
- "namespace" = A Namespace. :)

> Short name duplication in the system namespace is avoided by the system 
> maintainers, as usual.

Yes. And as I have said numerous times before - I also think it should
be avoided "across namespaces" because even if you *can* have name
clashes it doesn't mean that it is *good*. It still pollutes our minds.

That is also why my proposal relies on "auto export" of all names so
that name clashes between namespaces become apparent to all of us. If
you haven't played with my code you may not understand what I mean with
this, an example:

Let's pretend we have these classes:

Fruits::Orange
Fruits::Apple
Colors::Orange
Trees::Oak


Now, if I type in code in class Apple then I can write "Orange" and it
will resolve without prompts or anything. And it will render it short.
Fine.

If I type in "Orange" in a method in class Oak then it will ask me
"Fruits::Orange or Colors::Orange?" (using a popup menu) and I need to
choose. And it will be rendered in its qualified form.

So... this means that if there is indeed name clashes between namespaces
then the developer of class Oak will notice this by these damn prompts -
and the code looks "ugly" because it is fully qualified. Thus there will
be a natural tendency to avoid clashes - which is GOOD. Would it affect
this specific example? No, I don't think so because both names are
"correct". I can't see why one would be renamed.

This means that fine - if a developer has BOTH these namespaces inside
his image then he will just have to pick one when entering a short name
AND he will just have to read the qualified name in the browsers.
Period. But note that if he *didn't* have Fruits in his image there
would be no problem.

> The system namespace in my lightweight namespaces proposal would have no 
> name. This means that if we need to refer to it by name anyway, we would 
> use the empty string. This gives complete consistency in the syntax, 
> with ::Set meaning the class with the short name Set in the system 
> namespace.

Well, I want to still be able to call it "Smalltalk". But I agree that
the "::Set" syntax might be a good thing to have. Though it would only
be used in namespace Foo when Foo has a Foo::Set.

> Referring to the system namespace by name would not be something one 
> needs very often.

Well, try references to #Smalltalk. :)

> One instance would be when have a package that is in a 
> user namespace, and you want a particular class in that package to be in 
> the system namespace. This is still something you want, but you won't 
> need it for most code, because most of the time it will be just right 
> for the code for a class in a particular package to be in the namespace 
> of that package.

Still I don't see the need to be able to put "packages" in namespaces. A
you said - let's keep it simple - why not just settle with having this
as a "class attribute"? Simple. Works. No problem with existing tools
etc. Also note that we currently don't have a single "Package" concept.

> Cheers,
> 
> Peter

regards, Göran