Hi!
goran@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