For me the key question is what do we ***really gain *** vs the cost?  
What is the difference between each of us
systematically using a prefix? Really I do not see. Because to avoid  
conflict SD:: should be reserved to me exactly as before.
Ok cool we will have a tool that will not show SD::. Do we want the  
complexity of having nested namespace/import.../

I'm not sure. Now do we want to have import per package and a scope  
per package. I do not know.

I think that simplicity is nice. When VW introduced namespaces we  
talked a lot and thought a lot of what they would
bring. I'm still really perplex by the introduced complexity vs the  
gain.

The key questions I'm trying to understand after all these years  
looking at module system/namespaces/... is how
do they help in achieving scalability. Do we need selector namespace?  
Also where do we put import is crucial: do we want to have more Unit  
like parametrized modules by having a bind outside the module or is  
the import declared inside the using package?

I discussed once with the schemers and they told me that in fact they  
had problems with their model and they had to modify it (but never  
publish the problems they got). They discovered that but only by  
building complex app and having to change them.

> Göran Krampe wrote:
>> Foo::Bar == (Smalltalk at: #'Foo::Bar')
>> In fact, I believe it was you Andreas that strongly suggested I  
>> should do
>> it this way or take on a world of hurt. :)
>
> Right, because it's the only way to make it so that the tools would  
> continue to work (since none of them is namespace aware).
>
>>> So basically you're trading the probability of conflicts (reduced  
>>> due to
>>> the increased length in names) with the severity of conflicts  
>>> (increased
>>> since changing the prefix is more expensive).
>> Ehm, how can it be more expensive? You mean compared to changing a  
>> single
>> clashing class name?
>
> Yes.
>
>> And it *does* enable experimentation with prefix hiding (as I do  
>> in the
>> tools part) or even experimenting with explicit imports (which I  
>> detest -
>> and even Stephane now seems to think is a bad idea - but hey, feel  
>> free to
>> play around).
>
> Interesting. I'm just the other way around - I detest the idea of  
> tools rewriting source code under my feet and have code in the  
> morning look different from the same code in the afternoon, and  
> have code that would perfectly compile in the morning not compile  
> in the same way in the afternoon. And, I think imports are critical  
> for scalability - because they a) declare dependencies explicitly  
> and b) allow the *user* of a package/global to decide under which  
> name to use them. The Python module system works that way and it  
> works great.
>
>>> But since it's "only" an incremental shift in tradeoffs I wonder  
>>> if a
>>> language change (with significant costs for compatibility) is really
>>> justified.
>> Is the "language change" really of that kind? You can already have  
>> global
>> names with : in them (which is funny) but if you try using that for a
>> class you will get into trouble - a bug IIRC. So the small changes  
>> could
>> even be considered to be a bug fix. :)
>
> Hardly so. Code that doesn't work in any previous Squeak version  
> and doesn't work in any other dialect cannot be called a bug fix.  
> It's a significant syntax change.
>
>> I agree that it deliberately does not involve dependencies, and  
>> only a
>> little bit about visibility (the tool extensions I did have some
>> visibility mechanisms) - because I think we can first add the *basic*
>> notion of "named buckets" (=Namespace) and the *basic* syntax -  
>> without
>> blending those two issues into the pot.
>> If someone then would want to tie these Namespaces into dependencies,
>> imports, modularity etc - then that is IMHO a "next step".
>
> Yes, and that's the major reason why I'm not violently against  
> it ;-) It *may* be a step that needs to be taken now but I'm still  
> wondering if we won't be stuck forever at this point because even  
> between the two of us we can't agree on some very basic notions  
> (imports or not). That's why I'm judging this independently of the  
> follow-on steps (which may or may not happen) and that's why I'm  
> wondering if changing the syntax at this point is really worthwhile.
>
>> BUT... if we intend to try to tackle those two beasts on the language
>> level (instead of say SM or MC level), then perhaps a Namespace  
>> "notion"
>> is a first step.
>> And it doesn't seem to be a dangerous step either. But it will enable
>> experimentation.
>
> Experimentation is already enabled by having it loadable from  
> SqueakMap. And there are quite some risks associated with it most  
> importantly that of inventing an esoteric construct that nobody  
> wants and nobody needs because we may not understand the needed  
> semantics well enough to make it work out in the long term.
>
>> To summarise - it reifies prefixes and makes them concrete and  
>> easy to
>> manipulate, and easy to spot. That is all, and since we *have* these
>> things already (prefixes) - then making them tangible, concrete, real
>> objects seems like a useful thing to do.
>
> I agree with all of that. What I'm not sure about is whether that  
> (on its own) is reason enough for a change in syntax. The trouble  
> with syntax is that once it's chosen and once a semantics is chosen  
> we're essentially set with it. So are we certain, are we  
> *absolutely* certain that we understand the semantics of that  
> change well enough to say that "yes this is the semantics we need  
> for the follow-on steps and it is extremely unlikely that we'll  
> need anything but that"? I'm not.
>
> Cheers,
>   - Andreas
>
>
>