[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.