Squeak and Namespaces
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Nov 29 09:03:05 UTC 2006
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....
> 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?
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).
>> - Andreas
More information about the Squeak-dev