[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
``There is one reason that argues against including methods in the third
argument. The user might think that an arbitrary set of methods can be
included. However, for the intended purpose, it only makes sense if all
the methods applicable to a particular set of arguments are included.''
Check-keyword-arguments is a pretty ugly function, at least in terms of
its interface. One reason to tolerate it is that it can be useful in other
situations. One of the situations might be as part of someone's funny CASE
system in which as methods are defined, all places in the current sources
that invoke the generic function are checked in a cursory way for those
invocations that might fail to pass the keyword arguments test on this
method. One might argue that this is a poor example, but why assume that
our intended use is the only use, especially if we are trying to
generalize check-keyword-arguments to make it palatable.
One of the interesting things about the whole check-initargs affair is
that it is one the few places where a lot of effort is being made to worry
about the behavior of incorrect programs. Remember, Common Lisp itself
tends to say nothing about the behavior of incorrect programs (there are
generally in error) and even the most that CLOS typically says is that
errors are signaled or generic functions are invoked in spurious
Here we are specifying the function that checks for a particular error.
To me, a program that contains both a :type slot option and a setf that
violates it is incorrect. We have gone to no effort to make it any easier
than programming to check these erroneous programs.
I have no worries that someone who is writing his own version of
make-instance could look in chapter 3 or 4 to find out how to do error
checking. Therefore, only a check-keyword-arguments that is more generally
useful justifies going beyond specifying a procedural definition of
make-instance that is reasonable only for correct invocations of it.