Re: Finding the applicable methods...
"Pascal Costanza (as pc at p-cos dot net)" <[email protected]> Tue, 14 Jul 2026 17:50:18 +0200
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-61B19C79-0A9D-4AD0-8A3F-10FD332A0C34 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There is no need to use CLOSER-MOP if you intend to use only LispWorks. CLOS= ER-MOP is only relevant if you want to write portable MOP code. Everything C= LOSER-MOP does can also be done in LispWorks. The LispWorks documentation sh= ows very clearly where its MOP implementation deviates from the CLOS MOP spe= cification. > On 14 Jul 2026, at 00:56, David McClain (as dbm at refined-audiometrics do= t com) <[email protected]> wrote: >=20 [...] >=20 > But before getting sidetracked into CLOSER-MOP, the LW version of COMPUTE-= APPLICABLE-METHODS returns in one case a direct method with specializers (T T= ) and an :AROUND method for the same specializers. But the :AROUND method is= listed after the direct method in the result: >=20 > (defstruct thing) ;; just to make a unique object type >=20 > ;; My GF is #=E2=80=99ORD:COMPARE >=20 > (compute-applicable-methods #'ord:compare (list (make-thing) (make-thing))= ) > =3D> > (#<STANDARD-METHOD COMPARE NIL (T T) 8280AD7C9B>=20 > #<STANDARD-METHOD COMPARE (:AROUND) (T T) 828056D3DB>) Yes, that can be the case. Compute-applicable-methods does not determine cal= l order, it only determines the applicable methods sorted by method specific= ity. Method specificity is only in terms of method specializers, method qual= ifiers don't play a role here. When two or more methods only differ in metho= d qualifiers, but not in specializers, they can show up in any arbitrary ord= er. > However, at runtime, it becomes clear that my :AROUND method is getting ca= lled first, as I would have expected. I find this by setting breakpoints and= then watching the debugger fall through the code. That's because the call order is only determined after compute-applicable-me= thods, namely by compute-effective-method. (There are method combinations wh= ere the least specific method can be called first, or where method qualifier= s have a very different influence on call order. See define-method-combinati= on in the CL specification for examples.) > So next, when I try to call: >=20 > (clos:compute-effective-method #'ord:compare=20 > clos::*standard-method-combination* ;; dis= covered by probing... > (compute-applicable-methods #'ord:compare (= list (make-thing) (make-thing)))) >=20 > =3D>=20 > (CALL-METHOD > #<STANDARD-METHOD COMPARE (:AROUND) (T T) 828056D3DB> > ((MAKE-METHOD (CALL-METHOD #<STANDARD-METHOD COMPARE NIL (T T) 8140B0DC03= > NIL)))) >=20 > Whch does indeed show my :AROUND method being called first. But the MOP sp= ec says this function should return an effective method and then a list of e= ffective method options. And CLOSER-MOP does the same thing as the LW versio= n. So both do the =E2=80=9Cwrong=E2=80=9D thing? What you see here returned by compute-effective-method is indeed the effecti= ve method. There is an additional step, not exposed by the CLOS MOP, which t= urns the effective method into an effective method function. There is nothin= g "wrong" here. > So, I have long known that LW departs a bit from the extant MOP spec, such= as it is=E2=80=A6 And I still have no problem with LW way of doing things. B= ut it does seem irritating that CLOS:COMPUTE-APPLICABLE-METHODS returns resu= lts in the=E2=80=9Dincorrect" order... Compute-applicable only contributes partially to the order, the final order i= s determined later. This is actually very well described in the CL specifica= tion, and also in the CLOS MOP specification. I hope this helps, Pascal --Apple-Mail-61B19C79-0A9D-4AD0-8A3F-10FD332A0C34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html class=3D"apple-mail-supports-explicit-dark-mode"><head><meta http-equi= v=3D"content-type" content=3D"text/html; charset=3Dutf-8"></head><body dir=3D= "auto"><div dir=3D"ltr"></div><div dir=3D"ltr">There is no need to use CLOSE= R-MOP if you intend to use only LispWorks. CLOSER-MOP is only relevant if yo= u want to write portable MOP code. Everything CLOSER-MOP does can also be do= ne in LispWorks. The LispWorks documentation shows very clearly where its MO= P implementation deviates from the CLOS MOP specification.</div><div dir=3D"= ltr"><br><blockquote type=3D"cite">On 14 Jul 2026, at 00:56, David McClain (= as dbm at refined-audiometrics dot com) <[email protected]> wrote= :<br><br></blockquote>[...]</div><blockquote type=3D"cite"><div dir=3D"ltr">= <div><br></div><div>But before getting sidetracked into CLOSER-MOP, the LW v= ersion of COMPUTE-APPLICABLE-METHODS returns in one case a direct method wit= h specializers (T T) and an :AROUND method for the same specializers. But th= e :AROUND method is listed after the direct method in the result:</div><div>= <br></div><div><div><font face=3D"Monaco">(defstruct thing) ;; just to= make a unique object type</font></div><div><font face=3D"Monaco"><br></font= ></div><div><font face=3D"Monaco">;; My GF is #=E2=80=99ORD:COMPARE</font></= div><div><font face=3D"Monaco"><br></font></div><div><div><font face=3D"Mona= co">(compute-applicable-methods #'ord:compare (list (make-thing) (make-thing= )))</font></div><div><font face=3D"Monaco">=3D></font></div><div><font fa= ce=3D"Monaco">(#<STANDARD-METHOD COMPARE NIL (T T) 8280AD7C9B> </= font></div><div><font face=3D"Monaco">#<STANDARD-METHOD COMPARE (:AROUND)= (T T) 828056D3DB>)</font></div></div></div></div></blockquote><div><br><= /div><div>Yes, that can be the case. Compute-applicable-methods does not det= ermine call order, it only determines the applicable methods sorted by metho= d specificity. Method specificity is only in terms of method specializers, m= ethod qualifiers don't play a role here. When two or more methods only diffe= r in method qualifiers, but not in specializers, they can show up in any arb= itrary order.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"= ><div>However, at runtime, it becomes clear that my :AROUND method is gettin= g called first, as I would have expected. I find this by setting breakpoints= and then watching the debugger fall through the code.</div></div></blockquo= te><div><br></div><div>That's because the call order is only determined afte= r compute-applicable-methods, namely by compute-effective-method. (There are= method combinations where the least specific method can be called first, or= where method qualifiers have a very different influence on call order. See d= efine-method-combination in the CL specification for examples.)</div><br><bl= ockquote type=3D"cite"><div dir=3D"ltr"><div>So next, when I try to call:</d= iv><div><br></div><div><div><font face=3D"Monaco">(clos:compute-effective-me= thod #'ord:compare </font></div><div><font face=3D"Monaco">  = ; &nbs= p; clos::*standard-method-combination* ;; discover= ed by probing...</font></div><div><font face=3D"Monaco"> =  = ; (compute-applicable-methods #'ord:compare (list (make-thing) (= make-thing))))</font></div></div><div><font face=3D"Monaco"><br></font></div= ><div><font face=3D"Monaco">=3D> </font></div><div><font face=3D"Mon= aco">(CALL-METHOD</font></div><div><font face=3D"Monaco"> #<STANDARD= -METHOD COMPARE (:AROUND) (T T) 828056D3DB></font></div><div><font face=3D= "Monaco"> ((MAKE-METHOD (CALL-METHOD #<STANDARD-METHOD COMPARE NIL (= T T) 8140B0DC03> NIL))))</font></div><div><br></div><div>Whch does indeed= show my :AROUND method being called first. But the MOP spec says this funct= ion should return an effective method and then a list of effective method op= tions. And CLOSER-MOP does the same thing as the LW version. So both do the =E2= =80=9Cwrong=E2=80=9D thing?</div></div></blockquote><div><br></div><div>What= you see here returned by compute-effective-method is indeed the effective m= ethod. There is an additional step, not exposed by the CLOS MOP, which turns= the effective method into an effective method function. There is nothing "w= rong" here.</div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><= div>So, I have long known that LW departs a bit from the extant MOP spec, su= ch as it is=E2=80=A6 And I still have no problem with LW way of doing things= . But it does seem irritating that CLOS:COMPUTE-APPLICABLE-METHODS returns r= esults in the=E2=80=9Dincorrect" order...</div></div></blockquote><br><div>C= ompute-applicable only contributes partially to the order, the final order i= s determined later. This is actually very well described in the CL specifica= tion, and also in the CLOS MOP specification.</div><div><br></div><div>I hop= e this helps,</div><div>Pascal</div><div><br></div></body></html>= --Apple-Mail-61B19C79-0A9D-4AD0-8A3F-10FD332A0C34-- _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html