Hi!
Btw, if any of you haven't read my last little article on my proposal, here it is, it is short and funny :) :
http://swiki.krampe.se/gohu/32
Bert Freudenberg wrote:
Actually, that is the beauty of the proposal. Colons are already allowed unquoted in a symbol. #My::Class is valid right now. In this proposal, the compiler knows *nothing* about namespaces. It just permits a colon in a global identifier. It's the only syntax change.
Is that really true? I haven't looked at the code in a while but Goran
I haven't either - so I will begin by replying from memory - it might be slightly incorrect. I can check later tonight.
used code that I had originally written and that code most certainly wasn't just permitting colons in a global identifier. What it did do was introducing explicitly scoped variables and the result of Foo::Bar would depend on what is stored in Foo's scope under the name of #Bar and not on what is stored under Smalltalk at: #'Foo::Bar'.
IIRC what we did was to add as you say a new "explicitly scoped variable" in the actual parser BUT the actual lookup implementation used when that method is triggered was implemented as "what is stored under Smalltalk at: #'Foo::Bar'".
The instances of Namespace in my code behave like Dictionaries so if you have a Namespace 'Foo' then:
Foo == (Smalltalk at: #Foo) "the Namespace itself is a global"
(Foo at: #Bar) == Smalltalk at: #'Foo::Bar' "Namespace>>at: will simple look it up in Smalltalk so it is only emulating being a Dictionary"
...and of course:
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. :)
Of course, these two can be made the same by using the same association but that's still quite a bit different from just permitting colons in global names.
It uses the same association.
Generally speaking, I'm -1 on the proposal, mostly because what the proposal doesn't achieve is to make a real step towards enabling scalability of development (which to me is really what we're after). That's because the *author* of some code still needs to find unique names (prefixes) that do not conflict with the rest of the world and
Two "solutions" to this:
1. Let us make SM track prefixes. 2. Make it really easy to "remap" one namespace to another when loading code.
The last idea is that the system can check for such "remaps" when filing in code (or similar) and if there is one (say from SM->NewSM) it simple asks "Code uses Namespace 'SM', should I put this in SM or in the alternative NewSM?"
that a "change of prefix" becomes very, very expensive because it's literally like renaming all of the classes at once (and consequently breaking all of the code that uses any name from that "prefix space").
Yes, it is literally renaming - but it still feels quite easily doable.
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?
It's an incremental approach that shifts tradeoffs but doesn't do anything to address the problem on a more fundamental basis (in all fairness, Goran never claimed it did but it's important in this discussion to understand what this proposal does and doesn't do to assess the impact of a change).
Indeed it is not a "Grand Scheme" - but I still find it to be a useful next step that enables more advanced mechanisms as we learn and go forward.
It still is *compile time binding*. It does not change the fundamental mechanism (still uses the Smalltalk system dict) but it *does* introduce the concept Namespace (and class) and "reifies" them as globals.
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).
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. :)
And new code will work fine in an old Squeak - as long as you add those trivial tweaks (2-3 method changes IIRC) needed to have global names with :: in them.
It seems to me that the practical gain is fairly minor and there is little motivation that I can see for anyone with a "serious" project to adopt this solution given that it will neither be portable nor backward-compatible. Put on top that the proposal deliberately doesn't take a stand on any general modularity issues (visibility, dependencies), then what exactly does one gain?
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".
To me the basic question here is: Is the prefix pattern so pervasive (and so problematic) that it deserves a special syntactic representation? Without taking a stab at the "real" problem (scalability of development) my answer is: No. It's a clever hack but nothing that I would loose sleep over if it weren't there (and I won't loose sleep over it being there either but I'd like us to be clear about what we're trying to achieve with adopting it).
I more or less agree. :-o Class collisions is NOT a large problem in Squeak - dependencies and modularity on the other hand ARE increasingly so.
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.
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.
Cheers,
- Andreas
regards, Göran
PS. I had more or less given up on ever seeing the code in official Squeak, since there always seem to be people against it. I was happily surprised by Bert's post, but I don't expect nor dare to hope :) that it ever will enter Squeak. But I still think it is a good, neat step and if "the people in charge" decide that we will include it I gladly whip the code some more. It is very small btw, feel free to look and read class comments.