[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Readers, methods, and congruent lambda lists
- To: firstname.lastname@example.org.EDU
- Subject: Readers, methods, and congruent lambda lists
- From: Jon L White <jonl@lucid.COM>
- Date: Wed, 17 Oct 1990 19:46:39 PDT
- Cc: email@example.com
- In-reply-to: "Joe Konstan's message of Wed, 17 Oct 1990 15:06:01 PDT <90Oct17.firstname.lastname@example.org>"
re: I would like to define methods that take keywords and that have the same
name as slot-readers: For instance:
. . .
This results in an error based on incongurent lambda lists:
Yup, you can't do that in CLOS. Methods for a named generic function
seem to allow overloading of the name for that function, but you can't
do just any old overloading; in particular, the lambda-list congruency
issue will intrude. There is discussion galore in the archives on this
issue, if you care to read through it.
Although it probably won't be quite as efficient as using the automated
reader methods, many implementations of CLOS that I'm familiar with will
do some sort of optimization of SLOT-VALUE in the limited context presented
by writing your own reader method. E.g.,
(defmethod snoop-around ((x big-room) &key constraints)
. . . a random method body . . .
(defmethod snoop-around ((x duplex) &rest ignore)
;; a user-written pseudo reader method.
(declare (ignore ignore))
(slot-value x 'basement))
This latter method will probably be relatively speedy; it may be twice as
slow the super-optimized :reader methods, but it won't be 10 to 100 times
as slow, which is what an unoptimzed call to SLOT-VALUE could be.
On the other hand, many folks who might have to read your source code
would probably find it easier to do so if you took your third solution.
-- JonL --