Bulent Murtezaoglu <email@example.com> wrote:
| >>>>> "RW" == Rob Warnock <firstname.lastname@example.org> writes:
| RW> That said, if all you want to do is catch calls that fail to
| RW> hit some explicitly-specializing method, then wrap a macro
| RW> around DEFGENERIC that defines a method with no specialized
| RW> args (a.k.a. specialized on T for each arg), and put an ERROR
| RW> call there.
| True enough, but he'd get kicked into the debugger anyway if CLOS can't
| find an applicable method. No? How is a catch-all method that calls
| error an improvement on this? He wanted something to warn at compile
| time anyway. Now I am confused both about the question and your answer.
| RW> Or am I missing something obvious about your question?
| The same thing I am prolly. Am I missing something about your answer?
Yeah, actually, I think *I* missed something about my answer, like
going far enough to make it useful... ;-}
I guess I was thinking about the situation where you had a *very*
general method, say, PRINT-OBJECT, that might have reasonable defaults
for objects in T and subclasses of other types, but where you wanted
to do something specific for subclasses of your own class FOO. Then you
could have the "error" method specialize for FOO, which would catch any
calls for args of subclasses of FOO that *didn't* have PRINT-OBJECT
(or whatever) methods specialized for them. Hmmm... As I recall, there
was even some discussion of this very thing a while back when trying
to ensure that only subclasses of certain classes were permitted to
be instantiated. Something about making INITIALIZE-INSTANCE error when
called on the parent class, and having INITIALIZE-INSTANCE specialized
on the children *not* do CALL-NEXT-METHOD (or something).
And as far as your observation that "He wanted something to warn at
compile time anyway" goes... Oops. I missed that bit. Mea culpa.
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607