Squeak and Namespaces

Andreas Raab andreas.raab at gmx.de
Wed Nov 29 18:54:36 UTC 2006


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




More information about the Squeak-dev mailing list