Hi!

(should have replied to Brad, but for technical reasons I don't have the
original posting available)

>>From: brad fowlow <fowlow at pacbell.net>
>>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.

But IMHO this is not a weakness in the Namespace design - it is instead
something we can deal with in numerous of ways on the tool side.

For example, I have played around with marking short names as "shy" which
would make them not appear in pop up menus and not force other non-shy
names to appear qualified. This would then be used for "private" short
names - it is like the inverse of an import, a non-export.

The problem is of course where to store this attribute - as a property on
the class would be neat but then we get the whole "backwards compatibility
problem", or perhaps we can pull an Avi-trick and use some Category
convention etc. etc.

But it doesn't *invalidate* the base solution.

>>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.

Again - this is the NAIVE and SIMPLE approach - if there are multiple
short names we present them qualified. But there is no end to the tricks
or policies we can pull - for example, today in my implementation I still
show "local" references unqualified, because I think that is a good
compromise.

>>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.

I am unsure what you mean with "insulation" but my solution offers just as
"insulated" spaces AFAIK. You can't break code unless you collide with
namespace names - and all other systems I know of has that problem too.

>>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)

But that is YOUR CHOICE. Just turn off the hiding and nothing changes. :)
Or we can add another tool setting where you tell Squeak what code is
YOURS and it could ignore the other peoples code when deciding if it
should hide prefixes or not. Etc etc.

>>then the proposal doesn't really give me namespaces... it's namespace
>>emulation.

No, it is not emulation. The spaces are separate - your space can never be
affected unless you file in code using the same namespace name - just like
in Java or whatever language.

>>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)

Please realize that the "syntax change" you refer to is about allowing $:
in *global references*. As both I and Ramon has made clear you can ALREADY
create globals/classes with $: in their name (!). Either *that* is a bug
or the fact that you later *can't reference them by their name* in your
code is a bug.

IMHO calling this a "syntax change" is a bit on the harsh side. Croquet
(or is it Tweak?) allowing positional argument syntax - that is a much
larger change IMHO.

>>that could begin to fork the world into ::-dependent and ::-free code?

Hehe, we have tons of other ways of making code "forked" - like depending
on Monticello or depending on Traits etc etc. As I have shown we are
talking about 4 method mods and one added method. All in all it is (let me
count)...

12 added lines and 7 modified lines of code. This is all you would need
AFAICT at this moment to have ::-code working, see:

    http://swiki.krampe.se/gohu/35

I bet we can make this work in all Squeaks released to date with minimal
effort.

>>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?

Ah, the "let's wait for something even better" argument. Well, it sure is
a killer. :)

>>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.

Hehe, yeah... a "weak intermediate solution". So if I make it much more
complicated we can call it a Strong Enterprise Industrial Strength
Solution? :)

>>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).

Sure, weird and uncommon must be bad. Let's just turn Squeak/Smalltalk
into one of the "other languages" by emulating how they work - that seems
better - let's add imports and... hmmm, we could even start putting the
classes in files on disk - then it would be much simpler to find those
import statements! :)

Sorry for ranting. I am tired. No offense intended, really. And as I have
said - I have no high hopes so I don't know why I get worked up all over
again. Habit I guess.

regards, Göran