[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Difficulty with lambda-list congruence, specifically &KEY
- To: kanderso@DINO.BBN.COM
- Subject: Re: Difficulty with lambda-list congruence, specifically &KEY
- From: email@example.com
- Date: Mon, 12 Mar 90 08:36 CST
- >from: ihlpf!lgm (Lawrence G Mayka +1 708 713 5166)
- Cc: commonloops.pa@Xerox.COM
- Redistributed: commonloops.pa
>Don't forget that processing &key arguments is expensive, you probably
>don't want to do it for every function call.
Ideally, only methods that actually use the keyword arguments need
to "process" them. Older methods need merely discard the (unused)
More importantly, our criteria of extensibility, upward
compatibility etc. need not apply to all function calls, only to
generic functions that represent interfaces between software
>I don't think that adding &key's will provide all the extentability
>you'll need in an evolving system.
No, but together with the other features of ANSI Common Lisp and
CLOS, they can go a long way.
>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.
A prime criterion is to evolve the system without disturbing old
code. Changing old code can break existing features - an
intolerable catastrophe as far as our customers are concerned.
Besides, engineering constraints (e.g., continuous uptime,
real-time response) encourage the redefinition of as little code
Lawrence G. Mayka
AT&T Bell Laboratories