Re: [Sbcl-devel] validating a built-in superclass

[Christophe R. <cs...@ca...>]

Nick Levine <nd...@ra...> writes:

> As a warmup exercise for a newbie, I thought I'd pick a simple bug and
> fix it.

Excellent!  Welcome :)

> I ended up looking at 861004 (DEFCLASS fails to signal an ERROR when
> inheriting from a BUILT-IN-CLASS). What struck me as odd after a
> little digging was (method validate-superclass (class
> built-in-class)). It considers five named superclasses, such as
> *the-class-t*, and if your superclass is one of these then
> validate-superclass just waves you through.
>
> Can anyone explain this to me?

A few classes are allowed to be subclassed, through various extensions:
STREAM is the obvious one (to allow Gray streams to happen), and its
subclasses FILE-STREAM and STRING-STREAM; this means

  (defclass fundamental-stream (stream standard-object) ())
  (defclass fundamental-file-stream (file-stream fundamental-stream) ())
  (defclass fundamental-string-stream (string-stream fundamental-stream) ())

can indeed "just work" (and this isn't something that the user can make
"just work" for themselves by defining their own method).

Similarly, SEQUENCE is in there so that users can define their own
sequence classes, with e.g.

  (defclass doubly-linked-list (sequence standard-object) 
    ((node :initarg :node)))

and (subtypep 'doubly-linked-list 'sequence) would then be true.  (It's
of course the user's responsibility to define all the other protocol
methods to make instances of DOUBLY-LINKED-LIST actually behave like
sequences).

I'm not sure what the T class is doing in there, mind you.

Cheers,

Christophe