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