[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Query on ISSUE: LOAD-OBJECTS
- To: Jon L White <firstname.lastname@example.org>
- Subject: Query on ISSUE: LOAD-OBJECTS
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 25 Oct 89 13:16 EDT
- Cc: X3J13@SAIL.Stanford.edu, Common-Lisp-Object-System@SAIL.Stanford.edu
- In-reply-to: <8910251456.AA28268@bhopal>
Date: Wed, 25 Oct 89 07:56:12 PDT
From: Jon L White <email@example.com>
It says somewhere in this proposal:
MAKE-LOAD-FORM of an object of * metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
Surely this can't mean "user-defined", since that would effectively prohibit
an implementation from using STANDARD-OBJECTs for internal purposes.
At the asterisk above I would insert "user-defined class and".
the next sentence in that paragraph is all that is really needed:
It is valid to implement this [default error-signaling behaviour] either
by defining default methods on STANDARD-OBJECT and STRUCTURE-OBJECT that
signal an error or by having no applicable method for those classes.
with the implication that user-defined classes of metaclass either
STANDARD-CLASS or STRUCTURE-CLASS will see no other system-provided
methods on MAKE-LOAD-FORM.
Yes, the idea was that user-defined objects would not inherit a method that
would do something they didn't want.
I don't know whether MAKE-LOAD-FORM has been put into the specification
yet. Perhaps the best way to address this issue would be to make the
writeup for MAKE-LOAD-FORM speak about conforming programs, rather than
about implementations. Then it wouldn't accidentally imply anything about
what implementations can and cannot do with their own internal objects.