reply to Moon on slot shadowing

[Dave.Touretzky@A.CS.CMU.EDU]

I can't accept Moon's argument that packages solve the slot shadowing problem,
not because I dislike packages, but because I feel their use is inappropriate
in this context.  Here are three points to debate:

1.  Packages should be used for coarse-grain control of name conflicts, not
fine-grain control.  In other words, I think it's necessary to put the
compiler, the window system, and the mail system in separate packages, but
I don't think we should force a naive user writing a small program to
spread his identifiers among several packages simply because we didn't give
him proper scoping mechanisms for objects.

2.  An analogy.  Suppose function BAR modifies a global variable N.  Function
FOO, which calls BAR, innocently binds a local N.  Should this break BAR?  Of
course not; that's what lexical scoping is for.  No one would advocate
putting FOO's N and BAR's N in separate packages in this case; lexical
scoping is a much more elegant solution.  

My slot shadowing proposal is a kind of lexical scoping for objects.  It can
operate within a single package.  I believe the slot name problem is one of
proper scoping of identifiers rather than of protecting against multiple
unrelated uses of a symbol, for which packages seem more appropriate.

3.  Users should be AUTOMATICALLY protected from inadvertent name conflicts
so they don't get screwed in the ways I warned about in my proposal.  This
might occur if slot shadowing were not provided as the default behavior.  If
we insist on using packages to keep slot names distinct, then I'd like to
see a description of how this might happen automatically, yet in a way that
allows the user to refer to his slot names in a convenient manner.  I find
the notion of objects whose slot names are spread across a constellation
of packages not very appealing.

-- Dave