🚀 go-pugleaf

In article <9208182008.AA19599@dice0> rharris@rdrc.rpi.edu writes:
>
>The problem is that the class pcl::structure-object is supposed to
>be a superclass of every class having metaclass structure-class, and
>this requires a change to the way defstruct works.
>I can think of three ways to fix this problem:
>
> (1) Change defstruct to :include the structure named structure-object whenever
>     an :include option is not provided and the name is not structure-object
>     and :type is not specified.  Move the definition of structure-object
>     from pcl/defs.lisp the place that defstruct is defined.  Then change PCL
>     to import the symbol structure-object from whatever package defined it.
>
> (2) Change typep and subtypep to simulate the effect of (1).
>
> (3) Change the macro class-test (pcl/methods.lisp), to be the following:
> [...]
>
>  Richard Harris


From an implementational and maximal portability standpoint, I would
suggest both (1) and (3).

July 92 PCL already redefines defstruct so that it has access to the
information in the defstruct for its structure-classes.  (It also, of
course, calls the original lisp defstruct macro).  Adding the check
to :include structure-object if an :include is not provided would
then be simple, and would have the desired effects on typep and
subtypep, without having the efficiency or portability problems
that changing typep and subtypep (2) might entail.

I would also change the CLASS-TEST macro as you suggest (3), since
there will always be some structures defined before PCL is loaded
that will therefore not :include structure-object.

These are obviously only partial solutions (pre-PCL structures being
the problem), but it's about the best that a portable CLOS loaded on
top of specific lisp implementations can do.

I'll make these changes to July 92 PCL and update it on parcftp, unless
somebody points out a problem that Richard or I haven't seen.

- Trent Lange