[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: 10 May 88 2141 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
So, why not take that same way out now? Presumably the slot-filler guy who
stuffs initargs into slots is able to signal an error at a reasonable
point, and that condition could be handled in make-instance etc. The
slot-filler guy should be able check all for the existence of all the
slots he was going to try to fill, so the condition can mention all bad
slots. Similarly, keyword arguments that are not acceptable to an
applicable method will also be signaled, and the method who notices it can
report all the keyword arguments it doesn't like or even all the
keywords the generic function and all applicable methods don't like.
This can't work. A sink for initialization arguments can look at an
initialization argument and say "this isn't one of mine", but it cannot
say "none of the possible sinks for initialization arguments claims this."
The sinks for initialization arguments for make-instance are slot-filling
plus three generic functions' applicable methods' &key parameters.
Something has to consider all four of them together.
Another alternative is to state that the initargs will be checked at
specified points in an implementation-dependent or unspecified way.
In other words, don't include a procedural definition of make-instance
and don't include check-keyword-arguments as a facility that users can
call for their own purposes. I was probably the first to suggest not
including a procedural definition, way back when, so I won't argue
against it, however I don't think you have a strong argument for it yet.
If you believe that all of the bad initargs must be determined at the same
time and you insist that the mechanism be exposed in chapters 1 and 2,
maybe it would be better for the second argument to be a list of methods
and provide a mechanism for getting all the applicable methods from a
generic function for some set of required arguments. In this way the
ugliness of check-keyword-arguments would be traded off against providing
something else useful to the user.
I don't see how this makes check-keyword-arguments less ugly. It just
rearranges its interface slightly. Moving compute-applicable-methods
from chapter 3 to chapter 2 would be okay with me if you think it
belongs there. Alternatively, we could decide that the standard-class
method for make-instance belongs in the part of chapter 3 that we don't
agree on yet and remove it from chapter 1. Or we could package the call
to check-keyword-arguments back up inside check-initargs, where it was
until recently, which requires us to introduce three additional versions
of check-initargs to be called by the standard-class methods for the
three other generic functions that can be called with initialization
arguments. To me that would be uglier.