comments on The Art of the Metaobject Protocol, Part 1

[Alan Snyder <snyder@hplsny.hpl.hp.COM>]

I have read through Part 1 of "The Art of the MetaObject Protocol".
I think it is excellent!  Well written.

I have a few comments.

On page 32, you might want to comment on why you are storing a form and
an environment separately, instead of just a closure.

Your examples would benefit from use of the :TYPE option to declare the
types of slot values, wherever possible.

In the same vein, how about using the package system to make explicit those
things that are available to the user?  For example, couldn't the package
system be used to protect against (setf (class-direct-subclasses ... )), which
is mentioned on page 48?

In section 2.1, you mention introducing class objects as part of the MOP.
However, if you were using a Scheme style, you would need class objects as
part of the vanilla user language (e.g. as the argument to make-instance,
instead of using a class name).  However, the class object could just be an
entity; it would not need any user-visible operations.  So, I think it is more
accurate to say that the class object is part of the vanilla user language and
the operations on class objects are part of the enhancement provided by the
MOP.

Page 35, the undotted i trick is cute, but I don't like it.  The problem
is that the undotted i is not recognizable!

Page 77: The phrase "creating class metaobjects" is misleading.  It should
be "creating instances of class metaobjects".

3.2.1: I've always felt that the "alternative class precedence lists"
example was given more press than it deserves.  It is so trivial.
Perhaps you should omit it?  The other examples are much deeper.

Page 93: There is no space in the name "CommonObjects".

Page 99: In a couple of places, you say that a method cannot be overriden or
redefined.  Wouldn't it be nice if CLOS let you declare that (and enforced
the declaration)?  Would it be a good example to use the MOP to implement
such a declaration???

Page 73: Why must an entire class be a database-class?  Why can't I define an
"employee" class and have both ordinary employee objects and database employee
objects?  You don't even discuss this as a possibility...

4.2.3: Encapsulated methods.  It's too bad that the generic function has
to know that the methods are encapsulated.  Why shouldn't one method
be encapsulated and others be ordinary???  (For example, why can't I define
a PRINT encapsulated method on a CommonObjects class?  [where PRINT is some
standard generic function] )  (Does the revision on page 128 allow this?)

For anyone who is aware of how long it took to develop the MOP, it would be
nice to have a summary somewhere of the things that were hard to get right.

It would be nice if you discussed compilation issues.

  Alan