Hi, Sorry for chiming in so late. One assumption that Christophe made in an earlier email is, I think, not correct: validate-superclasse doesn’t specify that it determines whether the class /superclass/ is suitable for use as a /direct/ superclass of /class/, but whether it is suitable as [just] a superclass of /class/. (So no mention of “direct” in the wording in AMOP, which implies that it applies to both direct and indirect superclasses.) So here is a reading that, I believe, makes the specs more consistent with each other: A CLOS implementation can ensure that users cannot define direct subclasses of T in some way independent of validate-superclass, but validate-superclass can be specialized by users to define /additional/ restrictions, and those restrictions are defined in terms of the (transitive) superclass relationship, not the direct superclass relationship. So T cannot be a direct superclass of a standard-class, which could be checked say by the defclass macro expansion or by ensure-class, but it is always a valid indirect superclass, and that is what validate-superclass - correctly - yields. This may sound like stretching things, under the assumption that the authors of ANSI CL and AMOP had all implications in their heads, which is not necessarily the case - especially since validate-superclass is only called on direct superclasses. However, it is the case that the specification for validate-superclass does make use of the terms “direct superclass” and (just) “superclass” in different places, so this is an indication that this distinction was made on purpose. Also note that the specification for validate-superclass explicitly states that it can also be called by user code, so maybe the idea was that from a user code perspective, covering both direct and indirect classes was considered more valuable. Does this make sense? Pascal On 30 Aug 2014, at 06:22, Alastair Bridgewater