allocation :none

[Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>]

    Date: Tue, 27 Jan 87 23:01 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    In Flavors, we spent a lot of time some years ago discovering that that
    style doesn't work very well.  It worked out a lot better to split the
    superclass into separate modules and then inherit whichever ones are
    wanted.

I just read an interesting paper about programming style for object
oriented programming, written by Dan Halbert and <someone> from the
Trellis/Owl group at DEC's eastern research lab.  It's based on their
experience teaching and helping users who were learning object-oriented
programming.  It comes to the same conclusion, and strongly suggests
this kind of organization.

It was hard to figure out the implications of :allocation :none.  One
example of a confusing case is where A inherits from B, B inherits from
C, C provides a slot S1, B declares S1 with :allocation :none, and A
declares S1 with :allocation :instance.  One's "built-in" paradigms
about the concepts of "shadowing" and "inheritance from outer blocks"
and so on can easily lead to the impresion that A's S1 is distinct from
C's S1, whereas they are actually the same slot, and slot attributes are
inherited by A from C even though B "doesn't have" slot S1.  It's also
confusing that instance of B "undermine" inherited methods from C that
refer to S1, by making S1 not be there any more.

I don't think this paradigm fits well into the overall proposal, and the
benefits of this feature seem relatively small compared to the extra
complexity and confusion that it adds to the specification.  We've run
into such things before, many times, during this design process.  I
suggest that we apply our usual treatment: remove this from the
specification per se, and leave it as a possible future feature, or
implemention-specific enhancement.