+1


>From: Andreas Raab <andreas.raab at gmx.de>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at 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://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk