Here are a few things that struck me just now, looking at
pdd15_objects.pod. (Though it may or may not be the right time for
dealing with them.)
1. The C<add_parent> operation doesn't say how the new parent
affects the MRO:
=item add_parent
$P1.add_parent($P3)
Adds a single parent to the class. It takes an instance of the
Class PMC.
Is it a "push" or an "unshift"? Better might be to have a
C<set_direct_parents> operation that takes an array of new local parent
classes and replaces the old array completely; that way, the programmer
can excercise full control. For ease/compatibility, a single class
object could be coerced to a singleton array.
2. The C<parents> operation doesn't say whether it returns the
direct parents or the full MRO list (Lisp calls these the
CLASS-DIRECT-SUPERCLASSES and CLASS-PRECEDENCE-LIST, respectively):
=item parents
$P1 = $P2.parents()
An accessor for the parents of the class. It returns an Array of all
parents. The accessor is read-only.
Looking at the code, it seems to return the direct parents; so how does
one get the MRO list?
3. It seems to me that you will need to maintain complementary links
in the reverse direction, equivalent to CLASS-DIRECT-SUBCLASSES, in
order to propagate slot and/or inheritance change information to
subclasses. In that case, it would be nice to have a C<direct_children>
accessor to fetch them.
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
