Squeak and Namespaces

stephane ducasse stephane.ducasse at free.fr
Wed Nov 29 08:42:39 UTC 2006


I agree with Andreas. Funny but true.
This is so important that you noticed that I even break my silence....

Stef

PS: I have been working with VW recently and I really found  
namespaces getting in my way all the time. Also the integration of  
namespaces
in VW is badly supported at the refactoring level and other tools. So  
this is often a pain.

PSPS: We have been thinking a lot of this issue and I'm even  
unsatisfied with what I thought would be interesting: package import  
level
where each class live happily in a package (the package resolves the  
import) and the programmer does not see namespace except at the boundary
when declaring imports but I finally do not like that solution  
because the cost is too big for the gain. I would like to see a real  
system
develop with it and see the pros and cons before really been sure. So  
certainly a PhD topic.


On 29 nov. 06, at 09:14, Andreas Raab wrote:

> 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
>
>




More information about the Squeak-dev mailing list