Squeak and Namespaces
J J
azreal1977 at hotmail.com
Wed Nov 29 17:58:03 UTC 2006
+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
More information about the Squeak-dev
mailing list
|