Nick Levine <ndl@...> writes:
>> From: Christophe Rhodes <csr21@...>
>> Date: Tue, 16 Apr 2013 14:37:56 +0100
>> A few classes are allowed to be subclassed, through various
>> extensions ...
> Is this facility documented anywhere for end users? If not, I'd be
> inclined to create the classes such as the following, as part of pcl:
> (defclass sequence:standard-sequence (standard-object sequence)
> (defclass sb-gray:standard-stream (standard-object stream)
> (defclass sb-gray:standard-file-stream (sb-gray:standard-stream file-stream)
> (defclass sb-gray:standard-string-stream (sb-gray:standard-stream string-stream)
> ... and then remove the permissive method (validate-superclass nil
> '(class built-in-class)) at the end of pcl.
The awkward thing here is that there are multiple extensions to stream
classes: not just Gray streams but also Franz' Simple Streams, and also
the As Yet Mythical Perfect Extensible Streams Which Don't Suck.
> The class sequence:standard-sequence might then be documented.
Yeah, I feel guilty about the way that this has become embedded, but
unfortunately I suspect that what users there are of the extensible
sequence protocol are directly subclassing sequence. True, we haven't
documented anything, but I think for what it's worth I'd prefer
special-casing sequence and the stream classes. Maybe that could be
done with removing the general method on (class built-in-class) and
having a four methods with EQL specializers?
> By the way, I noticed that the error following
> (defclass woops (structure-object) ())
> suggests the user should keep going by defining their own
> validate-superclass method. Surely that's poor advice?
Extremely! So a (standard-class structure-class) method which suggests
using :metaclass structure-class instead?
> I've got fixes to the above and checked that SBCL builds and passes
> its more extensive tests. What's the procedure for submitting a change
> for validation etc?
If the change relates to a single or a few launchpad bugs, then a patch
(as produced by git format-patch) sent to launchpad and tagging the bug
"review" is good. If it's more speculative or wide-ranging, then
patches sent directly to this list are fine too.
> Thanks. It's been a great (re)learning experience, whether you fancy
> my change or not.
It's great to have more eyes on some of these long-dormant problems.