Hi!

> 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 ;-)

Yes, those were not your exact words, didn't mean that. :)

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

Yeah, I presume there are multiple models that are simple enough to be
viable as a "next step" for Smalltalkers - I just haven't seen much need
for a more elaborate model - given that as we all know prefixes has served
us "kinda ok" up to now and that I have lots of fear for taking away the
"Smalltalk feel".

When people argue for "nested" spaces I would like to hear the actual
semantics intended. In other words - what does the child-parent
relationship mean? Is it that a child sees the same stuff that its parent
sees? Or is it that if you import the parent you also implicitly import
the child? Or the reverse? Or is it merely for organisational purposes?

I don't think that is at all clear. In java it seems to only serve two
purposes - organisational and an decreased probability of picking the same
"namespace name" that someone else has done.

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

I consider it to be a fair guess given the "rules" for when it is needed
to be shown. But yes, I will try to set up an experiment and we will see.

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

Will see when I get the time.

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

I meant that the GemStone model described - minus the *list* of namespaces
(thus making them on equal footing) - ends up being more or less my model
AFAICT.

It was not a general claim for all possible models using shadowing. ;)

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

This is of course debatable. Btw, the variation of allowing nested spaces
in my proposal (as you do in Croquet I guess) is not impossible. I just
think it would be nice to avoid if possible.

For example (thinking aloud) one could envision allowing nested spaces and
then use that to group names that are "private" to the namespace versus
those that are not private. Or "Shy" as I have called it before - meaning
that the "shy names" don't participate as candidates in the pop up menu
when you type a short name. Let's say we have:

Impara::Croquet::Shy::Component
Impara::Croquet::SomeClass
Seaside::Component
Foo::SomeClass

Typing "SomeClass" in a method in Bar::MyClass would ask me which one I
mean - because there are two "non local" such names in the image.

Typing "Component" in a method in Bar::MyClass would resolve without
asking to Seaside::Component and not involve the shy Croquet class.

One argument for using the term "Shy" instead of "Private" is of course
that it is just as accessible as any other name - if you refer to it more
explicitly.

As I said, only "thinking aloud". :) In the above variation allowing
nested spaces the child-parent would not have any semantics other than
being used in the "policy" of when to show names short and when to ask
which name you actually meant.

So the above model would be extremely easy to add to my proposal - I
think. I am not arguing in favor of it though. :)

regards, Göran