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