Name conflicts for names of instance variables

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Wed, 18 Sep 1985  00:02 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    ....Both Dave Touretzky and Rob Maclachlan have independently raised
    questions about the assumption (which CommonLoops shares with flavors)
    that if a class adds a slot (access function) named "FOO" when it
    already has a "FOO" by inheritance, then these are necessarily the same
    slot.  There are a lot of situations where this is treacherous.

Why should name conflicts for instance slots be treated any differently
from name conflicts for functions, or anything else that has a name?  In
other words, what are packages for?

A well-known problem with Flavors as traditionally constituted is the
use of keywords for accessing instance variables.  Using keywords in
this way means that the programmer can't take advantage of packages to
resolve name conflicts.  I think this is a separate problem, not
directly related to inheritance rules for instance slots.  Indeed, the
problem arises for all messages, not just instance-variable-accessing
messages.  I think the solution is obvious: using keywords in this way
was a mistake.

Over the past year we have been evaluating experience with the first and
second generation designs of Flavors, to unravel the good features and the
bad features of Flavors.  This is one of several problems we're aware of.

    Touretzky has written up a critque/proposal on this, and I will
    encourage him to send it in to this mailing list.

I'd like to encourage him also, in spite of my argument above that the
problem is a non-problem.