Squeak and Namespaces
J J
azreal1977 at hotmail.com
Fri Dec 1 06:32:24 UTC 2006
+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
More information about the Squeak-dev
mailing list
|