[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLOS lambda-list congruence
- To: David N Gray <Gray@DSG.csc.ti.com>
- Subject: Re: CLOS lambda-list congruence
- From: kempf@Sun.COM
- Date: Thu, 15 Dec 88 09:52:13 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Your message of Thu, 15 Dec 88 11:22:46 -0600. <2807198566-13859327@Kelvin>
The lambda list congruence rules are designed to re-enforce the generic
function as an interface mechanism. In this design, the lambda list
is the interface to a distributed implementation, namely the methods.
The congruence rules match the generic function interface to the
implementation. This is a fundamentally different design from old Flavors
(but similar to new Flavors, see Moon's paper in the 1986 OOPSLA Proceedings).
Therefore, a simple syntactic transformation may be insufficient to handle
I ran into a similar problem doing CommonObjects on CommonLoops. CommonObjects
allows methods defined on different classes to have the same name but
differing lambda lists. In CommonObjects, methods are defined on classes
as in old Flavors or Smalltalk, so classes form individual namespaces
for methods. This is semantically distinct from generic functions, where
the package system is used to form namespaces.
If you want to preserve the old semantics, and alternative is to implement
your own generic function type using the metaobject protocol, which
relaxes the restriction on lambda list congruence.