[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Firs set of comments on TAOTMOP part 2
- To: mop@arisia.Xerox.COM
- Subject: Firs set of comments on TAOTMOP part 2
- From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
- Date: Wed, 31 Oct 1990 13:30:00 PST
Comments on Volume 2 of "The Art of the Metaobject Protocol..."
3-7 first paragraph of Classes section:
A class metaobject determines the structure and
behavior of its instances.
Reason: Methods can also be EQL specialized.
3-8: second paragraph
Reason: Sounds better to me.
3-8: third paragraph
Certain kinds of information
3-8: 4th par.
3-8: second bullet
as a function of no arguments
3-8: fifth bullet
those generic functions
Rem for which there are
3-8: first bullet for generic functions section
the name is available as a function name.
What if the generic function is unnamed?
3-9: 4th bullet in Methods
I can't find a definition for this, so I can't say whether or not I can
go along with this.
3-10: I think that there should be a class STANDARD-DEFMETHOD-METHOD
with direct superclasses STANDARD-METHOD. STANDARD-DEFMETHOD-METHOD is
what DEFMETHOD would normally expand into. One reason is that accessor
methods have no need of a METHOD-FUNCTION, but ones defined by defmethod
3-11: 3rd par
described in the section "Special Metaclasses".
The referred to section needs something in it before these classes can
3-11: 4th par
3-12: end of 2nd bullet
and in fact call-next-method is
Reason: Conditionals. Perhaps something should be said
about extensions which signal an error when things are inconsistent
being permitted. This whole area of extensions is getting way out
beyond what I think we have a good grasp on.
3-13: We need some concept of extensions to method combinations. If
method combination MC allows methods qualified on qualifiers from the
set Q, then MC+, with accepted qualifiers Q+ is an extension of MC iff Q
is a subset of Q+ and MC+ behaves identically to MC when methods are
qualified with qualifiers only from Q, and adding methods qualified from
elements of Q+ not in Q will not change the order in which those methods
qualified from Q will execute. For example, the following would be an
extension to STANDARD:
(DEFINE-METHOD-COMBINATION STANDARD-ERROR-CHECKING ()
(PRIMARY () :REQUIRED T)
(FLET ((CALL-METHODS (METHODS)
(MAPCAR #'(LAMBDA (METHOD)
(LET ((FORM (IF (OR BEFORE AFTER ERROR-CHECK (REST PRIMARY))
(PROGN ,@(CALL-METHODS BEFORE)
(CALL-METHOD ,(FIRST PRIMARY)
`(CALL-METHOD ,(FIRST PRIMARY) ()))))
`(CALL-METHOD ,(FIRST AROUND)
All the generic functions use STANDARD method combination, or an
extension of it.
3-13: Last bullet
Portable metaclasses cannot be redefined.
Why not? I can see why user code shouldn't go around redefining the
standard metaclasses for the same reason they shouldn't be allowed to
redefine CAR, but I can't think of any reason to disallow it for
user-defined metaclasses. I think the CLOS implementation should just
make this kind of thing happen automatically via inheritance.
3-17: I can not accept the section for parsing of DEFCLASS, since it
prohibits compile-time checking for spelling mistakes in option names.
3-18: The figure is obsolete and inconsistent with page 3-17.
If I define the PLANE class with documentation, and then redefine it
without documentation, what makes the documentation go away?
3-19: As stated previously, I can not accept the macroexpansion for
3-19: Methods -- I'd still like to let the method body be involved in
choosing the method's class. For example,
(DEFMETHOD FOO-X ((THING FOO))
(SLOT-VALUE THING 'X))
should be able to turn into a reader method. This helps while expanding
method combinations, a topic which I hope to get into the CLOS report.
I think I sent a proposal for how to make DEFMETHOD, etc. do this back
3-21: The above excepted, this expansion looks about right.
3-21: third par of Processing Method Bodies
ensure-generic-function's :environment keyword -- How about just
saying that this is an allowed keyword, the details of which are