Hi Roel!

Roel Wuyts <Roel.Wuyts at ulb.ac.be> wrote:
> One simple question I had when reading the proposal (and before really 
> giving comments):
> 
> What exact problem do you want your namespaces to solve (I am not 
> talking about the primary values of your solution)?
> Is it name clashes?
>
> (several people here want to solve different things with the 
> "namespaces" - from simple naming conflicts to different scope lookup 
> mechanisms to more packaging-issues to deployment to .... So I'd like 
> to be sure :-) )

Hehe, such a question bodes not well. :) Andreas has a very immediate
need in his projects (not sure exactly what it is though) and I am more
thinking about making Squeak a better place for our circa 400 (and
growing) packages on SM etc.

So I am probably trying mostly to:

1. Make packages less likely to conflict. This means that yes, it gives
a package a way to have named objects (classes) in its own little space
and be sure that those names are "ok" - meaning that future other
packages will not stomp all over them. I didn't write about that - but
to make this "fool proof" we would need to register unique Namespace
names in say SM. Much like the PIs are today. Hey, perhaps they are
simply the same? :)

2. Not any real difference in how "scope lookup mechanisms" I think.
Well, the qualified syntax is introduced and the Namespace object
probably too - meaning that we have two new "tools" we can think about
and use. For example, it wouldn't be too far off to think about swapping
one Namespace for another. Given Namespaces we could in theory load two
Socket packages into the image at the same time - one in "Sockets" and
another in "CoolSockets". So CoolSockets::Socket and Sockets::Socket are
available at the same time. I could one or the other by direct
qualification, but I could also perhaps swap these Namespaces. Or at
least map "Sockets" onto "CoolSockets". Food for thought.

2. Packaging and deployment. Well, the only thing I can think of "off
the top of my head" is that a package which only has classes (or other
objects) in its own Namespace, would always be installable into an
image. Either in its own Namespace or - in a worst case scenario - in
another Namespace given by the user. The simple fact that we at least
*have* multiple places where we can put the classes makes it quite
simpler, no?

Not sure if this made you any wiser. :)

Please remember that my proposal is just a little, simple, humble
proposal. It is not a fancy cool Classbox or anything like that. But it
seems to me it could go a long way nevertheless, and perhaps it is so
simple that we could actually introduce it without people screaming
bloody murder. :)

Note that it would:
- Not introduce any new steps when programming. No "first create your
namespace" or "first add an import".
- All old code would still look and work the same. (I think)
- Only introduce a rather simple addition to the class template that can
be default-filled rather easily.
- Add a new syntax for qualification (the "::") that Squeakers don't
even need to write - it will be auto corrected for them. :)

In short - I am proposing to chop up the Smalltalk Dictionary into a
Dictionary of Dictionaries. :)
But coupled with a few tricks that I described it feels like it could
work pretty good.

regards, Göran