[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

:allocation :none



    Date: 26 Jan 87 14:33 PST
    From: Ken kahn <kahn.pa@Xerox.COM>

    I thought I should explain the original motivation for :allocation
    :none.  There are two expected uses of it.

    1) A subclass implements an inherited slot procedurally (i.e. it defines
    accessor methods) and doesn't need any storage set aside. :allocation
    :none just saves some space in each instance but has no semantic import
    (except maybe with respect to low-level slot access, i.e. slot-value).

    2) A slot is not needed by a subclass.  Declaring it :allocation :none
    is both a cheap way to get an error if the instances really do need it
    and again a way to save space in instances.

    So I guess I'm agreeing with Moon that the slot continues to exist but
    certain kinds of access to it are errors.

    To some extent, the value of :allocation :none depends upon the style of
    object-oriented programming.  One style is to put alot of functionality
    in the super-classes which sub-classes turn off.  E.g. an
    immovable-window is a subclass of ordinary window and needn't waste
    space for slots used only in supporting movement.

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 haven't thought about it real deeply, but I think the Common
Lisp object system is similar enough to Flavors that it will work out
the same way.

If you believe this, maybe we should get rid of :allocation :none, since
it seems to make slot inheritance a lot harder to document and to
understand.