A lightweight namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Apr 22 12:48:17 UTC 2004


Hi Peter!

Peter van Rooijen <peter at vanrooijen.com> wrote:
> Hi Goran and all!
> 
> I have been lightly monitoring the namespace discussion and I believe 
> that with Goran's latest proposal we are reaching the stage where 
> something is going to happen. I applaud you!

:) Reading through your post I agree with much in it and will only
respond to a few things.

[SNIP of definition of problem and what is a namespace, I agree with it]
> So, now the two main questions have been answered, and we can look at 
> the related/derived questions:
> 
> Some related questions:

I elected to "answer" these very shortly according to my proposal and
how it is currently coded:

> 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.
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.

> 2) What is the relationship to packages?

IMHO none really. :) At least no technical relationship. But in practice
I think it will turn out natural for different packages to have one or a
few namespaces for themselves. But practice will show us - no need to
enforce anything AFAICT. It wouldn't surprise me if some packages end up
sharing spaces too.

> 3) What kind of resolution mechanism/rule is needed (if any)?

Well, my code has a proposed one. It can be further discussed. Check
class side of LookupContext. 3 methods.

> 4) Should namespaces be reified?

The word "reified" is a word I just recently bothered to look up. :) I
assume it means something like "should they be objects?". I think they
should, simply because in my experience almost all concrete things
eventually find a need to be an object. :) Currently we don't see much
state to put in them - except for the bindings - but I think the need
can materialize quickly.

> 5) Is there a root namespace, and if so, how should we refer to it?

Yes there is. Smalltalk. Same as always. :) In fact - you can load my
Namespace code and simply go on your business as before. Or at least
that is the idea - I might have missed something here and there.

> 6) Is there some kind of shadowing going on?

Yes, my proposed resolving-mechanism says that a short name found in the
"local" namespace ("local" meaning that the name has a binding in the
same namespace as the code which refers to it) is bound to that binding
without looking further.

Not though that we could/should probably warn when making that binding
etc.

> 7) How will this work with old/new code and forward/backward compatibility?

Well, I haven't thought it threw 100% but I think my proposal is very
nice in this respect.

> 8) Should code in a namespace only recognize/resolve short class names 
> in its own namespace and the root namespace, or optionally others as 
> well (suggesting reification and an import mechanism).

My code auto resolves short names from other namespaces *if they still
are unique* in the image.
So no, it doesn't necessarily suggest an import mechanism IMHO.

> 9) Are multi-level namespace names allowed (Sm::Public::Set)?

Currently no. And I think we should see if the need really is there. I
hope not.

> 10) How should class references be compiled?

Currently *all* short names are resolved and stored in the actual source
String fully qualified.

> 11) How does code get to be 'in a namespace'?

Currently it is simply by naming the class when creating it or renaming
it. So if you pick a name like #Baffa::Haffa then suddenly you have a
namespace called Baffa and Haffa is in it.

> 12) How to guarantee uniqueness of namespace names?

I think SqueakMap can help us in that. And we can also add some
remapping mechanisms so that stuff can be put in a different namespace
when filed in.

> 13) What is the relationship with class and pool variables?

Currently none. Though I agree that pools could possible be handled much
in the same way. Not sure about all the problems though.

> Some answers (or statements/observations suggesting answers):
> 
> The classes that are now already in the base image, can (and should, in 
> my opinion) all go in the same namespace. No Collection::Set, 
> Magnitude::Float or Network::Socket (these are examples of 
> namespace/package confusion).

Well, I agree that we shouldn't create namespaces mapping to the top
level categories (as my conversion script does). My script just did it
to show how a partitioned system could "feel" and "look". Note though
that it is currently borken. :)

> I would advocate keeping it all very simple by making the root namespace 
> have *no name*. This makes the root namespace unique syntactically and 
> avoids all discussion about naming it Smalltalk, Squeak, Root, or whatever.

I agree by assuming you mean that we simply keep Smalltalk as before. So
"Transcript" still refers to the global in the "root" space, namely in
Smalltalk.

> So you write Set to refer to whatever Set is seen/visible from where 
> (i.e., in which namespace) the code is, and if you absolutely want the 
> one in the root namespace, you write ::Set. This suggests that if you 
> write Set and you are in the namespace SqueakMap, you will get 
> SqueakMap::Set if it exists, so it suggests the possibility of 
> shadowing, which I in fact advocate.

Personally I don't "advocate" it - but I still think it should be
possible. :)
The ::Set syntax doesn't work currently in my implementation, but that
could be added.

I also think we might want to add the "shyness" mechanism because if
someone shadows say "Set" in his package then given my current
implementation a developer will be asked "Did you mean Set or Foo::Set?"
each time he types "Set", which very quickly would drive people nuts. :)
But that is the whole idea - shadowing is also a kind of pollution of
our "mental" namespace - this default behaviour of the tools will keep
it clean. I would hate to have to keep track of "Set" being in 3-4
different commonly used packages.

> Of course if you write Set and your code is in the root namespace, it 
> can only refer to ::Set. Very nice for existing code in the distribution 
> images, it is not affected at all :-).
>
> It would be simplest, and work just fine, to have only one level of 
> namespaces, and all code sees only the short class names in itself and 
> the root namespace. Multilevel namespaces, imports (explicit and/or 
> implicit), it can all be added later if and when it is deemed useful, 
> after some significant experience with a two-level system has been gained.

Exactly. And I still think we will not need to introduce imports. :)

> Code gets to be in a namespace by virtue of a declaration. If it is 
> without a namespace declaration, it is in the root namespace. If a class 
> has a namespace declaration in its definition, all its methods are in 
> that namespace. If a class has no namespace declaration, but its package 
> has one, the namespace of the methods of the class are the namespace of 
> the package. The namespace of a package is also used for resolution of 
> class and pool names in all class definitions in that package.

This all sounded a bit "overly complex" IMHO. My implementation simply
relies on the class name.
If the name is Foo::Bar then that class is in namespace Foo. If it is
just Bar, then it is in Smalltalk. Can't see the necessity to be able to
declare the namespace on another additional level like a "package".
 
> Namespace name uniqueness is handled by a social mechanism. Since 
> namespaces in this lightweight namespaces proposal aren't defined by 
> themselves, but are implicit in class and package definitions, 
> declarations of namespaces with the same name refer to the same 
> namespace, and you can't have duplicate short class names in the same 
> namespace. If there is no conflict in short names, two authors can 
> accidentally choose the same namespace name and the code will load 
> together and even work!

Yes, but with a registry on SM and also some remapping mechanism then I
think we will be ok.

> Class variables and imported (in the class definition) pool variables 
> still resolve before (and thus shadow) the other names.

Yes, same as before. I didn't touch that AFAIK.

> Namespaced names 
> (from the root namespace or the non-root namespaces) are a replacement 
> for the single global namespace of classic Smalltalk.

Well, I would rather say that qualified names complement the global
namespace of classic Smalltalk. Meaning that you can still use
"Smalltalk" for globals just like before and the namespace objects
themselves are in there.

> Finally:
> 
> I really believe that it can be this simple, and that this is really 
> useful, in this simplicity. Not having implemented it, I hope I didn't 
> miss something that makes this proposal not work :-).

Eh... I just assumed you had looked at my implementation.

You didn't touch upon the principles of rendering short names (when
possible) in the tools and using only qualified names in the actual
source.

> I will be happy to 
> try and respond to criticisms, and just as happy to clarify what isn't 
> clear if someone should be interested in clarification.
> 
> Cheers,
> 
> Peter

regards, Göran



More information about the Squeak-dev mailing list