+1
From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Wed, 29 Nov 2006 00:14:11 -0800
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 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'. 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.
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 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").
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). 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).
But since it's "only" an incremental shift in tradeoffs I wonder if a language change (with significant costs for compatibility) is really justified. 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?
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).
Cheers,
- Andreas
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...