goran at krampe.se wrote:
> Eh, IMHO they are just as much "namespaces" as any other kind.
> And moving to a multiple-dicts internal implementation - which I btw
> considered - is much, much harder.
> In fact, Andreas told me to just don't go there - it is a world of hurt.

Well, I don't think that is *quite* what I said (unless you have a quote 
to back it up ;-) but generally, yes, complex means of searching nested 
namespaces can get problematic very quickly. If anything, that was one 
of the lessons I took away from the 3.3 modules where effectively 
everything always included everything else and wanting to "not-include" 
anything became an outright adventure. But I do think there are a few 
ways to make that search mechanism explicit and clear (for example, by 
avoiding transitive import chains).

>> With your set up, every class that is in a namespace has to have some ugly 
>> colon syntax.
> 
> But as I have said many times now - only visible very seldomly.

Given that nobody has used that solution so far, how do you know?

>> And we have a lot of prefixes now, so it is pretty reasonable 
>> to expect lots of ugly colons to look at after the change.  And if I want to 
> 
> I disagree, I would say it is pretty reasonable to not expect lots of
> them. But this I intend to demonstrate in fact, so we will see.

I'd be a really interested in seeing an experiment along those lines.

>>> GemStone thus has shadowing - the spaces are like layers on top of each
>>> other - a space early in the array can shadow a space later. Good? IMHO it
>>> would just get confusing and error prone *in the context of Squeak* . I
>>> simply don't see the need for shadowing like this - others may disagree -
>>> read on for an interesting side effect.
>> Yea, I think we could live without this part in the base.
> 
> Eh, but that is an INTEGRAL part of the GemStone setup. That is the
> whole idea with having a LIST in the first place.
> If you don't want shadowing then you land on my proposal. :)

Huh? And why would that be? I fail to see why not having shadowing 
necessarily ends up with your proposal - I can imagine various namespace 
implementations not having shadowing and not being the same as yours.

>> And I am with you on not making namespaces so granular.  Sometimes, even 
>> with python, if the problem is small enough most of the code is import 
>> statements.  One of the things I like about smalltalk is that it isn't like 
>> that.

I don't find that an advantage considering the alternative of a single 
humongous namespace that you have to probe for trying to find an unused 
name for your project. In particular if it is (like in Python) coupled 
with stating the dependencies, e.g., the packages that you are going to 
require.

Cheers,
   - Andreas