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


PS: I have been working with VW recently and I really found  
namespaces getting in my way all the time. Also the integration of  
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  
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  
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