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