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

Re: Printing Objects



From Gregor:

>Be warned, I am going to (mostly) dump on using printing for dumping.
>
>The reason defstruct has a readable representation for printed objects
>is because defstruct is broken in this (and many other) regard.  I
>believe the default printed representation of defstruct types lulls
>programmers into a false sense of believing that the problem of dumping
>and restoring has been solved for them when in fact, that is not at all
>true.

From Dan Weinreb:

>    4) The hooks should be part of the metaobject protocol, since the
>    metaobject protocol controls the representation of classes and
>    instances.
>
>I don't agree with this; it would be a real pain in the neck, and
>overkill, to have to define a whole new metaclass just to say how an
>instance is printed.  Defining a method is far easier.

Yow! Ok, let's forget it then. The default PRINT-OBJECT can print
out in a nonreadable form, and it's up to the user to take care
of printing in a class or metaclass specific way.

From Gregor:

>Here is a related question?
>
>What happens if an object appears as a constant in a piece of code that
>is being compiled to a file?  CLtL certainly is not clear on what
>happens if a defstruct-defined structure appears in such a place.  Is
>print-object what you would like to call here??

In fact, CLtL doesn't specify how a constant ANYTHING gets compiled into
file. It doesn't even specify that two references to a constant 
which are EQ during compilation will be EQ after the compiled file
is loaded. The only thing which my reading of CLtL seems to indicate
will be EQ is an interned symbol, and then only if the package exists
in the load environment.

I don't think you can realistically expect PRINT-OBJECT to be of use
here, since everyone will have a different low level representation
within compiled code files. The motivation for having a readable format
was for easy exchange of objects between machines, and the ability
to store objects in some default format, like DEFSTRUCT. But, as was
pointed out, a general solution is probably still a research question.
For examining the internals of an object, DESCRIBE (87-002, pg. 2-37)
or INSPECT (CLtL, pg. 442, but not in 87-002) could be used.

		Jim Kempf	kempf@hplabs.hp.com