Hi !
There's something that I currently fail to understand with these functions.
Perhaps some MOP expert can enlighten me...
Consider the following sample code (it defines a subclass of
standard-generic-function and specializes c-a-u-c and c-a-m):
(defclass my-generic-function (standard-generic-function)
()
(:metaclass sb-mop:funcallable-standard-class))
(defmethod sb-mop:compute-applicable-methods-using-classes
((mgf my-generic-function) classes)
(multiple-value-bind (methods ok) (call-next-method)
(print "FOOBAR")
(values methods ok)))
(defmethod sb-mop:compute-applicable-methods
((mgf my-generic-function) arguments)
(let ((methods (call-next-method)))
(print "FOOBAZ")
methods))
(defmacro defmygeneric (function-name lambda-list &rest options)
`(defgeneric ,function-name ,lambda-list
(:generic-function-class my-generic-function)
,@options))
(defclass myclass ()
((slot :initarg :slot :reader myslot)))
(defun make-myclass (slot)
(make-instance 'myclass :slot slot))
(defmygeneric my-function (obj))
(defmethod my-function ((obj myclass))
(myslot obj))
Here's what I get with it:
CL-USER> (defparameter *myobj* (make-myclass "slot"))
*MYOBJ*
CL-USER> (my-function *myobj*)
"FOOBAR"
"FOOBAR"
"slot"
[ twice ? Hmm, anyway ]
Now, if I omit the specialization of c-a-m, here's what I get:
CL-USER> (defparameter *myobj* (make-myclass "slot"))
*MYOBJ*
CL-USER> (my-function *myobj*)
"slot"
So the specialization on c-a-m-u-c is silently ignored. I also have done the
test using after-methods instead of primary ones, and the result is the same:
if I specialize only c-a-m-u-c, it is ignored.
I'm aware of the consistency issue with these two functions, but still, this
behavior feels wrong to me. I found nothing that could explain this in the
AMOP.
Also, as a side question: there seems to be an a c-a-m function as well as the
sb-mop: one. But that's not the case for c-a-m-u-c. Why ?
Thanks.
--
Check out my new jazz CD on http://www.didierverna.com/ !
Didier Verna EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22
Didier Verna wrote:
> Hi !
>
> There's something that I currently fail to understand with these functions.
> Perhaps some MOP expert can enlighten me...
>
>
> Consider the following sample code (it defines a subclass of
> standard-generic-function and specializes c-a-u-c and c-a-m):
[...]
> Here's what I get with it:
>
> CL-USER> (defparameter *myobj* (make-myclass "slot"))
> *MYOBJ*
> CL-USER> (my-function *myobj*)
>
> "FOOBAR"
> "FOOBAR"
> "slot"
>
> [ twice ? Hmm, anyway ]
>
> Now, if I omit the specialization of c-a-m, here's what I get:
>
> CL-USER> (defparameter *myobj* (make-myclass "slot"))
> *MYOBJ*
> CL-USER> (my-function *myobj*)
> "slot"
>
>
> So the specialization on c-a-m-u-c is silently ignored. I also have done the
> test using after-methods instead of primary ones, and the result is the same:
> if I specialize only c-a-m-u-c, it is ignored.
>
> I'm aware of the consistency issue with these two functions, but still, this
> behavior feels wrong to me. I found nothing that could explain this in the
> AMOP.
Yes, I think you spotted a case where SBCL seems to be too strict in the
interpretation of AMOP. On the other hand, I don't think being that
strict is a bad idea in itself. From a functionality perspective, it
wouldn't have hurt to make it more strict in the CLOS MOP spec...
> Also, as a side question: there seems to be an a c-a-m function as well as the
> sb-mop: one. But that's not the case for c-a-m-u-c. Why ?
c-a-m-u-c was a late addition to the CLOS MOP to allow for extensions of
the kinds of specializers while keeping a certain level of efficiency
that you would lose when there were only c-a-m to specialize on.
c-a-m was apparently already part of the CLOS design when ANSI Common
Lisp was standardized.
Note that the feature set of ANSI CL was frozen around 1989 and AMOP was
published around 1992.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Yes, I think you spotted a case where SBCL seems to be too strict in the
> interpretation of AMOP. On the other hand, I don't think being that strict
> is a bad idea in itself.
Oh, but wait ! Lisp is the language of freedom, we shoudn't impose
anything on anyone ! (sorry, couldn't resist :-) :-)
> From a functionality perspective, it wouldn't have hurt to make it more
> strict in the CLOS MOP spec...
Agreed. However, what's questionable is the fact that the
specialization on c-a-m-u-c is *silently* ignored. A warning would not hurt I
guess.
> c-a-m-u-c was a late addition to the CLOS MOP to allow for extensions of the
> kinds of specializers while keeping a certain level of efficiency that you
> would lose when there were only c-a-m to specialize on.
>
> c-a-m was apparently already part of the CLOS design when ANSI Common Lisp
> was standardized.
>
> Note that the feature set of ANSI CL was frozen around 1989 and AMOP was
> published around 1992.
OK. Thank you.
--
Check out my new jazz CD on http://www.didierverna.com/ !
Didier Verna EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22
Didier Verna wrote:
> Pascal Costanza wrote:
>
>> Yes, I think you spotted a case where SBCL seems to be too strict in the
>> interpretation of AMOP. On the other hand, I don't think being that strict
>> is a bad idea in itself.
>
> Oh, but wait ! Lisp is the language of freedom, we shoudn't impose
> anything on anyone ! (sorry, couldn't resist :-) :-)
;)
The point is, there's little freedom to gain here... ;)
>> From a functionality perspective, it wouldn't have hurt to make it more
>> strict in the CLOS MOP spec...
>
> Agreed. However, what's questionable is the fact that the
> specialization on c-a-m-u-c is *silently* ignored. A warning would not hurt I
> guess.
That's true.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/