Re: Difficulty with lambda-list congruence, specifically &KEY

[kanderso@DINO.BBN.COM]

  Redistributed: commonloops.pa
  From: lgm@ihlpf.att.com
  Date: Wed, 14 Feb 90 09:39 CST
  >From: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166)
  To: commonloops.pa@xerox.com
  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
  difficulty?