SLOT-OBJECT is a PCL convenience, allowing for shared definitions in
class initialization and slot access on conditions, structure objects
and standard objects. The non-PCL parts of the system don't place
a layout for SLOT-OBJECT in the layout-inherits of structures, so
TYPEP was reporting NIL always.
Effectively, though, SLOT-OBJECT is the union of STRUCTURE-OBJECT,
STANDARD-OBJECT and CONDITION, so inform the classoids of this. In
the process delete what must be dead code in CLASS-TEST, because
SYSTEM-CLASSOID has not named a type for quite some time.
* TYPE-CLASS-INFO can be represented in 5 bits holding an index to the
respective element of *TYPE-CLASSES*. Pack those into TYPE-HASH-VALUE.
* Remove logic from cold-init that patched in a TYPE-CLASS to each
CTYPE instance that was constructed in genesis.
* Use the same number of hash bits regardless of machine word size.
Remove cold-init logic to "improve" hashes produced from cross-compilation.
The LCG PRNG is quite possibly just as random as an address-based hash.
* Use deterministic hashes for CLASSOID, like for LAYOUT.
* Rename TYPE-CLASS-INFO accessor to TYPE-CLASS.
* Change TYPE-CLASS from a DEF!STRUCT to a regular DEFSTRUCT.
the universal superclass is a special-case for validate-superclass.
That has knock-on implications on its metaclass (can't be
built-in-class) which means we have to document an exception to
another part of AMOP.
SB-KERNEL::COMPUTE-EFFECTIVE-SLOTS got the source and destination
mixed up.
The fact the test didn't actually test anything didn't help.
Fixes lp#1300904.
In order to get slot definition initialization right, move the
readers/writers slots to direct slot definitions, and write code to
detect all the bad cases documented in the MOP dictionary at
initialization time. Condition slots also need changing, to have
separate initform and initfunction information. Moving the slots
breaks metacircle resolution, naturally, so rewrite that to find the
relevant reader/writer information from the direct slots at runtime.
The irony of having to rewrite metacircle detection and resolution for
a bug tagged "easy" on launchpad is not lost on me.
Originally reported by Bruno Haible at some point in prehistory,
probably around December 2004, lp#309072.
Previously we only accepted a list designating the method combination, but
since MOP also specifies a way to grab the actual method combination, we
should really accept that as well.
Fixes bug 936513.
"The class standard-object is the default direct superclass of the
class standard-class. When an instance of the class standard-class
is created, and no direct superclasses are explicitly specified, it
defaults to the class standard-object."
"The same is true for funcallable-standard-class and
funcallable-standard-object."
* Add :DEFAULT-INITARGS to that effect.
Fix remaining slot name publicness in standardized classes.
... be cowardly and just rename TYPE to %TYPE, but write a
comment about why this isn't really good enough.
... now we can test for our interpretation.
... document it, too
The class SB-PCL::STD-OBJECT is now useless: delete it
mercilessly.
... this means that there are no direct instances of STD-CLASS
any more: so it can be removed from the braid.
... document that we're no longer nonconforming wrt
{,funcallable-}standard-object
Declassification of INSTANCE and FUNCALLABLE-INSTANCE.
It turns out that the classes INSTANCE and
FUNCALLABLE-INSTANCE, as expressed in instance-pointer-lowtag
and funcallable-instance-widetag, are incompatible with the
MOP's notion of classes: the types INSTANCE and
FUNCALLABLE-INSTANCE are necessarily disjoint (no instance can
have a widetag of anything other than instance-header-widetag),
but FUNCALLABLE-STANDARD-OBJECT is required to be a subclass of
STANDARD-OBJECT, and must therefore have the superclasses of
STANDARD-OBJECT among its superclasses. If INSTANCE is one of
those, FUNCALLABLE-INSTANCE cannot be, so F-S-Os would not be of
type FUNCALLABLE-INSTANCE (which is wrong); if it is not one of
those, then ordinary S-Os would not be of type INSTANCE (which
is wrong). CMUCL, at the time of writing, exhibits type system
confusion in this area, as demonstrated by CSR cmucl-imp
2005-09-0x).
So, we need to do something else; probably most straightforward
to make INSTANCE and FUNCALLABLE-INSTANCE named types, as they
are of the same order of specialness as e.g. T -- not quite as
special, but almost. Some hacking later...
... the usual type system dance. Play whack-a-mole with test
failures and compilation failures until they all go
away. Primtype, class, typetran, and so on are
fiddled with.
... somewhat hacky code for determining when a class is subtypep
instance / funcallable-instance.
... different hard-coded constants for genesis; don't make a
special instance-layout, because the instance class is
gone.
... just to prove we've achieved something, make STANDARD-OBJECT
a superclass of FUNCALLABLE-STANDARD-OBJECT.
(Supporting METAOBJECT should be straightforward now)
... many many new tests, both of the before-xc variety (it's
amazing in how many ways I can get the type system
wrong) and of the regular form. Also add some
ctor tests that aren't exercised yet.
