[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MAKE-METHOD arguments discussion
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: MAKE-METHOD arguments discussion
- From: Gregor Kiczales <Gregor.pa@Xerox.COM>
- Date: 6 Jan 87 14:31 PST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Mon, 5 Jan 87 23:31 EST
- Sender: Gregor.pa@Xerox.COM
Date: Mon, 5 Jan 87 23:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Oh, gross! What is the reason for wanting this?
Let's not start this again. I don't think this is gross. In fact, I
think it would be gross not to do it this way. The point is, that with
meta-objects, it is more natural than before for the user to write code
which grovels around in the data-structure of the object system (the
meta-objects). In this kind of code, it is perfectly natural to want to
invoke a method's function.
I think it is bad modularity to push whatever slot access optimization
implementations may want to do into the user's face, by tacking extra
arguments onto method functions where the user can see them.
Specifically, I think the way this is done in flavors (with
self-mapping-table as the first argument) is bad modularity, because the
user should be allowed to think that when they type:
(defmethod foo ((arg0 class) arg1 arg2)
(equal (si:all-args-to-this-function) (list arg0 arg1 arg2)))
foo will return t.
Of course this particular piece of code is not such a good example, and
any example will not be portable, by my point remains valid --
implementations should hide implementation details from the user.
Sure, but doesn't using method-lambda constitute blessing the
Yes and No. Yes, in that I don't really think method lambda is
necessary, and I am not a big fan of it. No in that I think
method-lambda is different than what I thought you meant by blessing the
function. Here are some examples which may illustrate the difference.
(flet ((make-method (specs function)
'argument-specifiers (mapcar #'class-named
;; In this example, a previously compiled function is being used as
;; the method function of a method being added to foo.
;; This function does not expect to benefit from any optimizations
;; which might result if the compiler had known that its first
;; argument was going to be a rocket. All this function expects is
;; that it will receive one argument.
(add-method 'foo (make-method '(rocket) #'previously-compiled-fn))
;; In this example, a lambda expression is being used as the method
;; function of a method being added. The person who wrote this code
;; used method-lambda as a portable way of telling the compiler that
;; this function was going to be used as the method function of a
;; method with the argument specifiers as given in the method lambda.
;; Note that method-lambda does not authorize the compiler to change
;; the argument list of the lambda, the user must still be able to
;; get their hands on the method function and call it with one
;; all method-lambda authorizes the compiler to do is to compile the
;; lambda in such a way that it "is an error" to call it with an
;; that is not a plane.
(add-method 'foo (make-method '(plane) #'(method-lambda ((p plane))
;; This is an example of what I think of as bad blessing. In this
;; example, like in example-1, the user had a previously compiled
;; function which does not need to or expect to benefit from having
;; the compiler know the class of its first argument. But, in order
;; to make the underlying implementation happy, the user must have
;; the function blessed, which may return a function with a different
;; argument list.
(add-method 'foo (make-method '(blanket) (bless-us