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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061130/6b3fc5b4/attachment.htm