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

Firs set of comments on TAOTMOP part 2

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
Add    default
       behavior of its instances.
Reason: Methods can also be EQL specialized.

3-8: second paragraph       
Rem    in
Add    by
       the class
Reason: Sounds better to me.

3-8: third paragraph
       Certain kinds of information
Rem    is
Add    are
Reason: Grammar.

3-8: 4th par.
       available as
Rem    forms
Add    objects

3-8: second bullet       
       as a function of no arguments
Add    ,
Reason: Grammar

3-8: fifth bullet
       those generic functions
Rem    for which there are
Add    with
Reason:  Simpler

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
       ... method-function-applier
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
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
be evaluated.

3-11: 4th par
       the class
Rem    es
       standard-object is
Reason: Grammar.

3-12: end of 2nd bullet
       and in fact call-next-method is
Add    always
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:

					     ,(REST PRIMARY)))
		      `(CALL-METHOD ,(FIRST PRIMARY) ()))))
			   (,@(REST AROUND)
			    (MAKE-METHOD ,FORM)))

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, 


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
in May.

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