+1.  Good points.

>From: brad fowlow <fowlow at pacbell.net>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Thu, 30 Nov 2006 02:56:22 -0800
>
>
>On Nov 30, 2006, at 1:52 AM, Göran Krampe wrote:
>
>>Note that you don't get penalized in my solution - BUT if you  spread your
>>package as open source (to lots of other users) then you will  inevitably
>>"pullute" our shared namespace of common short names. We want to be  very
>>careful about that pollution - because it muddles our brains.
>
>But that -is- a penalization, especially since it works both ways;  you 
>pollute me also.
>The overall point of the exercise is to facilitate wide sharing and  reuse 
>of code,
>so that's the basis of evaluation...  one measure of success is how  
>thoroughly
>protected we are from everyone else's naming choices.
>
>Those short names are pollution only because of the nature of the  
>solution.
>If I have to consider carefully whether or not to use a short name  for 
>something
>because it's a pain in the ass when someone else does too,
>that's a weakness of the namespace design.  Maybe a small one, but  
>irksome.
>
>If my day-to-day practical choices for nice code that others can  happily 
>reuse,
>without feeling polluted,  end up being:
>    a) pick both unique namespace names and unique unqualified names
>    b) status quo - pick distinctive names for everything, via plain  old 
>letter prefixing
>
>then it's no longer clear what I'm buying with the colons, except the  
>ongoing
>chance that anytime my code lands in an image alongside someone  else's who
>had similar naming tastes to me, we'll both be looking at more colons.
>
>OK, that's an exaggeration...  but it's a choice.      Explicit  
>disambiguation (imports)
>is mechanism that has a cost:  something more to attend to as a  
>programmer.
>It also has a value:  it's part of a proven pattern for strong  namespace 
>insulation,
>with all the grab&reuse freedom that comes with that.
>
>If the insulation is porous (for instance, if other people's code can  
>affect,
>and can change from day to day, what I see in my editor when looking  at my 
>code)
>then the proposal doesn't really give me namespaces... it's namespace  
>emulation.
>But letter-prefixing is just as good as namespace emulation, and it's  more 
>honest;
>it doesn't pretend (especially to newcomers) to be something it isn't.
>And it doesn't require syntax adjustments or more editor pop-quizzes.
>
>Given that, do the merits benefit allotting a syntax change (a  valuable 
>commodity)
>that could begin to fork the world into ::-dependent and ::-free code?
>Or would it would be better to acknowledge that letter-prefixing is  just 
>about as good, and free, and already there,
>and hold out for  a stronger solution without colonizing the code  pool in 
>the meantime?
>
>Clearly, it's hard to wrangle a namespace change into this system.
>A somewhat weak intermediate solution that got any uptake
>could easily become a further moral hurdle
>that a stronger solution would have to accommodate;
>two kinds of legacy cases to reconcile,  rather than one.
>
>And I think that an environment where changes in unrelated code
>could change, at any time, what text you see when browsing your own  code,
>will strike people as a bit weird (to put it kindly).
>
>-b
>
>
>
>


>

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered 
by Pandora http://radio.msn.com/?icid=T002MSN03A07001