On Wed, 29 Nov 2006 09:42:39 +0100, stephane ducasse wrote:

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

Mind to address your requirements from the view of ClassBoxes?

/Klaus

P.S. *package* is just another word for *problem* ;-)

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