type specifiers in slot descriptors

[Paul P. Maglio <maglio%linus@mitre-bedford.ARPA>]

type specifiers in slot descriptors

In the St. Patrick's Day release of PCL we have found the following
silly behavior:

When defining a class with a slot whose type specifier is a list
and which has an accessor, e.g.

    (defclass foo
        ()
        ((slot1 :type (or integer symbol)
                :accessor foo-slot1))
      )

no accessor FOO-SLOT1 gets defined. If the type specifier had NOT been
a list, e.g. :TYPE INTEGER, no problem would have occurred. FURTHERMORE,
(here's the punch line), even if you REDEFINE the class FOO so that
slot SLOT1's type specifier is atomic, you will NEVER get that
accessor. There is effectively a black mark against that accessor.

So if you now do this:

    (defclass foo
        ()
        ((slot1 :type integer
                :accessor foo-slot1))
      )

you won't get any accessor because of the black mark mentioned above.
But if you then do this:

    (defclass foo
        ()
        ((slot1 :type integer 
                :accessor bar-slot1))
      )

you will get the proper accessor, BAR-SLOT1.

In trying to figure out why this happens, we came across a related,
though minor, bug.  A redefinition of a slot's accessor APPEARS to be
forced whenever the new slot's type specifier is NEQ the old slot's
type specifier, (in the function PCL::UPDATE-SLOT-ACCESSORS--CLASS-1).
Of course, this is always the case when the type specifier is
non-atomic.  Thus a slot's accessor APPEARS to be redefined whenever
the slots's type specifier is a list, e.g. (OR INTEGER SYMBOL). We say
the redefinition APPEARS to be forced because, as we mentioned above,
the accessor is forgotten by the time DEFCLASS returns.

For now, our solution is to remove our type specifiers altogether.

John Burger
Paul Maglio