Re: Printing Objects

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

    Date: Wed, 6 May 87 13:00:33 pdt
    From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>

    >     Date: Wed, 6 May 87 09:34:12 pdt
    >     From: Jim Kempf <kempf%hplabsc@hplabs.hp.com>
    >     
    >     Looking through the PRINT-OBJECT specification, there is no read macro
    >     specified for allowing an object printed out to be read back in. 
    >
    >I don't see why #S couldn't be extended to read instances. Since #S
    >can only read "typed" structures (those that define a common lisp type),
    >the semantics wouldn't get changed.

    That would be OK too. Looking at the specification of #S, it could
    be extended to anything with a constructor. The important point is
    that the extension be noted in the CLOS specification, so it doesn't
    get lost.

If we wanted a thing like #S for instances of standard classes, we would
certainly use #S rather than inventing another read macro that does the
same thing as #S.  However, there are some problems with #S.

Since we seem to be agreeing that the technique for creating objects
will not make the physical slots directly visible, but instead will add
a layer of abstraction, there is the issue that this transformation
may not be reversible:  It may not be self-evident how to convert the
slot-values of an object into a set of arguments to make-instance that
will create an object with the same slot-values.  Suppose that not all
of the slots have initargs that can initialize them.

If instead we made #S bypass make-instance's abstraction and specify
the physical slots directly, it would be a terrible violation of
modularity.  What this really shows, I think, is that only a method
for the class in question can know what is the proper way to create
an equivalent instance.

In addition to this issue of slot values, I don't think the concept
of "allowing an object printed out to be read back in" is well-defined,
because the concept of reading "the same object" is not well-defined.
In the simplest cases, creating an object of the same class with
slot values "printed out and read back in" will do the job, but only
in the simplest cases.  In general, an object is part of a data structure
and ripping the object out of that data structure and jamming it
into a world by itself may not be meaningful.  This is the same reason
why we don't provide a general copy-object function.

I think it would make sense to have a standardized mixin class for
those simple objects whose semantics are defined entirely by the
values of their initializable slots.  This class would define a
print-object method that used either #S(...) or #.(make-instance ...),
and would probably also define methods for copying and for dumping
into binary files output by compilers.  This is fine; the thing I
want to be very cautious about is assuming that -all- objects should
have these methods.  It's much better to package them in a mixin that
is there if you want it and not otherwise.  Any suggestions for a
good name for this class?  simple-object?