Sections 2.3 and 2.5

[Richard P. Gabriel <rpg@lucid.com>]

Of the three approaches Moon suggests, I favor a combination of
bringing some stuff into the main specification from the prototype
chapter 3 and flagging the rest as places for future extension.

I feel that the largest exposures we have are readers (but not
writers) for some things like these (this list suggested by Jonl):

class-direct-supers, class-direct-subclasses, class-direct-slots,
class-slots, class-direct-methods, class-precedence-list,
class-forward-referenced-supers, class-no-of-instance-slots,
method-function, method-generic-function, method-arglist,
method-qualifiers, method-specializers, generic-function-name,
generic-function-methods, generic-function-discriminator-code,
generic-function-lambda-list, slotd-name, slotd-allocation,
slotd-initform, slotd-initargs, and slotd-type.

Also we are exposed on the inability to make methods for add-method to
use. These are the places where I would consider trying move something
into the main specification.

Someone writes:

``p.2-3, para.3: Without meta objects one can't create anonymous
classes and improper class names, so much of this paragraph is
currently irrelevant.  Keep the first two sentences and the last
sentence, delete the rest.  [I think we should keep it anyway, but
flag it as a framework for future extensions --Moon]''

Hm, I thought CLASS-NAME was a SETFable place, as was FIND-CLASS, but
I guess that isn't true as it currently stands.

``p.2-4, para.3,4: Again the stuff about metaclasses is not relevant to
the current metaobject-free standard.''

Well, there are various metaclasses now (structure-class and
standard-class), and there are some places that talk about compatible
metaclasses. I can't believe it's reasonable to flush all mention of
metaclasses because you cannot create them. (Actually, you can, but it
isn't likely that you can do anything useful with them. For example,
you can do (defclass random-metaclass (standard-class)) and then
proceed to make instances of it which are hardly distinguishable from
ordinary standard classes.)

``p.2-5, bullet 3: changing "is shared by instances" to
"is shared by all instances" would be clearer.''

This is fine. Kathy, can you do this?

``p.2-5: Delete the 3-line inheritance section.  This section has been
reorganized into nonexistence.

p.2-5: Inheritance of Class Options should come after the class
precedence list section.''

Ok. Kathy, can you do this?

``p.2-9, Redefining Classes, Third paragraph:  The CLOS spec says when
slots aren't updated, X3J13 says when they are updated.  X3J13 doesn't
mention anything about changes to ordering.  [How come this spec.
doesn't say exactly the same thing as 88-002R here? --Moon]''

I don't quite get this. I have the Feb 14 X3J13 draft here (my March 21
draft is at work), and both the Feb 14 draft and 88-002R say this:

``Note that redefining a class may cause slots to be added or deleted.
If a class is redefined in a way that changes the set of local slots
accessible in instances, the instances will be updated.  It is
implementation dependent whether instances are updated if a class is
redefined in a way that does not change the set of local slots
accessible in instances.''

On the other hand, this paragraph appears on page 2-47 not 2-9, so it's
hard to tell whether we are all talking about the same thing.

``In several of these paragraphs, references are made to the "old class"
and the "new class".  It would be clearer to say "the old class
definition" and "the new class definition" since it's still the same
class object after the redefinition.''

I think there is ample distinction made in the first paragraph of this section
between the class object and the class. This section and others like it
are difficult enough to understand without extra words like ``definition''
being thrown in where that doesn't really aid understanding. Consider how
you would rewrite this using ``definition'':

``The value of a slot that is specified as shared both in the old class
and in the new class is retained.  If such a shared slot was unbound
in the old class, it will be unbound in the new class.  Slots that
were local in the old class and that are shared in the new class are
initialized.  Newly added shared slots are initialized.''

Here is a try:

``The value of a slot that is specified as shared both by the old
class definition and by the new class definition is retained.  If such
a shared slot was unbound in the class specified by the old
definition, it will be unbound in the class specified by the new
definition.  Slots that were specified as local by the old class
definition and that are specified as shared by the new class are
initialized.  Newly added shared slots are initialized.''

I'm not sure that this slightly more precise paragraph says anything
more than the original, and it is a lot harder to understand.

Finally, the classes might be EQ, but they are not equal as classes.
(1 2 3) and (a b c d e) might be EQ, but one is the old list and the
other is the new list, if one was derived from the other via
replacement.

			-rpg-