[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SETF-SUB-METHODS
- To: barmar@Think.COM
- Subject: Issue: SETF-SUB-METHODS
- From: Jon L White <jonl@lucid.com>
- Date: Thu, 29 Dec 88 03:52:05 PST
- Cc: cl-cleanup@sail.stanford.edu
- In-reply-to: Barry Margolin's message of Tue, 27 Dec 88 20:22 EST <19881228012217.3.BARMAR@OCCAM.THINK.COM>
re: What about users who
have implemented their own complex DEFINE-SETF-METHODs? Will they need
to change these if they wish their generalized variables to be
consistent with the language-defined ones? Or does this not affect the
return values from a SETF method?
Well, I won't say that a programmer who uses DEFINE-SETF-METHOD can't
shaft himself this way [by definition, DEFINE-SETF-METHOD is for the
"not easy" case]. However, this proposal seems more directed towards
stopping the premature optimization where "evaluating a subform" and
"doing the access" are falsly combined into one step. [The original
temptation to do so was when the sub-form was a symbol(?)] I rather
hope, as you suggest, that this proposal affects the return value
of a SETF method only to the degree that the related accessing and
storing forms don't make the premature optimization.
-- JonL --