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