instance/class dependency

[gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)]

    Date: Tue, 16 Oct 90 09:44 CDT
    From: ARTHUR@GUINEVERE.tamu.edu (Arthur Keen)

    Should the existance of an instance depend on the existance of its class?
    I can see reasons for and against this kind behaviour, vis a vis
    histories, permanent storage, program development, etc.  What is the
    prescribed behaviour of CLOS, and Statice in this situation?
    In flavors I found that...

    (defflavor gestaldt ()())

    (defmethod (yo! gestaldt)()
      (print "gottcha!"))

    (setq gestaldt-instance (make-instance 'gestaldt))

    #<GESTALDT 60136513>

    Kill the definition of gestaldt

What exactly did you do to "kill" the definition?

    Find out the type of gestaldt-instance

    (type-of gestaldt-instance)

    GESTALDT

    (describe gestaldt-instance)
    #<GESTALDT 334057201>, an object of flavor GESTALDT,
     has no instance variables.

    (typep gestaldt-instance 'instance)
    T

    ...BUT

    (typep gestaldt-instance 'gestaldt)

1    Error: GESTALDT is not a known type.

0    (yo! gestaldt-instance)
1    Error: The generic function YO! was applied to the argument #<GESTALDT 334057201>.
0	   1The argument was not of the correct type.
0	   1The function is implemented by no flavors.

0This all makes sense when you realize that, for efficiency reasons,
flavors do not retain pointers to their instances.  Thus "killing the
definition" of a flavor can have no effect on the instances directly,
but indirectly effects them because methods become unusable, the type
(flavor) is no longer defined, etc.

Updating of instances to reflect incompatible changes to their flavor is
accomplished via the method dispatch mechanism, not by way of pointers
from the flavors to instances.  This is a neat trick which I don't fully
understand (Moon can tell you more, of course), and it seems to work
flawlessly.