[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Printing Objects
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: Re: Printing Objects
- From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
- Date: Thu, 7 May 87 07:49:54 pdt
Leaving aside the question of whether to use #S and how to match
reading to MAKE-INSTANCE, couldn't the *PRINT-ESCAPE* switch play
a role about whether an object is printed out in a form which
is readable again? My reading of the description of *PRINT-ESCAPE*
on pg. 370 of CLtL is not clear. The first paragraph seems to
imply that this switch is supposed to primarily affect printing
of symbols with strange print names, the second paragraph seems
to imply that it serves a more general function in controlling
whether a "structure" (and by this I interpret CLtL to mean
any Common Lisp data structure, not just a DEFSTRUCT) gets printed
in a way which makes it readable again. Perhaps this switch could
be used for controlling whether the instance is printed in a
readable or nonreadable form.
Returning to the more general question, while I agree about the
desirability for compiling objects into a binary form and writing
them out, and other forms of saving objects, these will all be
machine dependent. Looking at other object-oriented languages,
one of the most attractive aspects of Objective-C to many programmers
is the Filer, a way of writing an object out in ASCII form. It provides
a kind of "lowest common denominator" persistence, and is a debugging
aid too. A programmer can send a Filer generated representation of
an Objective-C object around a local area network of diverse machines
without much extra code to do conversion from one form to another.
On the question of reading violating abstraction and who should
know how to print out an object, I think it is the metaclass rather
than the class which should know about how to print an object and
read it again. The metaclass controls the low level representation
of the object, thus should have the knowledge to decompose and write
it out, and read it in again. For FUNCALLABLE-STANDARD-CLASS, for
example, the metaclass method could do the same thing as is done
for a fundef. For STANDARD-CLASS, a default method could be provided
to read and write the object. Other metaclasses would need to supply
their own methods.
This should not, however, preclude a programmer from defining a method
on a class which writes an object in some nonreadable form.
I also agree that any read macro should go through MAKE-INSTANCE, to
avoid violating the class/object abstraction. Maybe some combination
of #S and #. could play a role, or maybe the default is simply:
#.(make-instance (class-named <name of class> <init-plist))
I think that it is important for this issue to be put into the
language spec once we have resolved it. With current Common Lisp,
there are a number of nonstandard read macros for creating the
underspecified types (e.g. #P for pathnames), which are
springing up due to need.
Jim Kempf kempf@hplabs.hp.com