[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Difficulty with lambda-list congruence, specifically &KEY
- To: email@example.com
- Subject: Re: Difficulty with lambda-list congruence, specifically &KEY
- From: kanderso@DINO.BBN.COM
- Date: Fri, 09 Mar 90 15:07:28 -0500
- Cc: commonloops.pa@Xerox.COM
- In-reply-to: Your message of Wed, 14 Feb 90 09:39:00 -0600. <900214-085750-8227@Xerox>
- Redistributed: commonloops.pa
Date: Wed, 14 Feb 90 09:39 CST
>From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166)
Subject: Difficulty with lambda-list congruence, specifically &KEY
Our group is attempting to use CLOS to maintain plug-compatible,
upward-compatible interfaces between the components of a large,
complex, long-lived, evolving software system. We are having
difficulty, however, with lambda-list congruence; specifically,
with the requirement that
If any lambda-list mentions &REST or &KEY, each
lambda-list must mention one or both of them.
This restriction means that if someone defines a method on a
generic function FUNC to take, say, a single (required) argument,
then no one else's later FUNC method can extend the FUNC interface
to accept additional (keyword) arguments; at least, not without
modifying the original FUNC method (which is not desirable from a
methodological point of view).
This seems to match your system requirement of plug-compatibility.
When you define your protocols you should be able to identify which
functions are likely to require &key arguments (such as make-instance).
One (methodological) workaround is to dictate the inclusion of
&KEY in the lambda-list of every method of every publicly
advertised generic function. This, however, is not possible for
automatically generated methods; in particular, slot accessors
(including readers and writers) take only required arguments.
Don't forget that processing &key arguments is expensive, you probably
don't want to do it for every function call.
Thus, either any publicly advertised generic function which counts
a slot accessor as one of its methods must be billed as
"nonextensible" in our terminology, or we must generate our own
accessors via DEFMETHOD (and thereby lose the benefit of any
accessor optimizations provided by the CLOS vendor).
I don't think that adding &key's will provide all the extentability
you'll need in an evolving system.
Why not let your protocol evolve over time. Your 1995 code could have
keywords, and your 1990 methods could be redefined to call the 1995
methods with default arguments.
Presumably we could use the meta-object protocol to define the
object system behavior we desire, but we're reluctant to take such
a step just yet. Does anyone have any comments or ideas about our