From 968bb35fbaf4d60b63fa6967bc36029bd5b12701 Mon Sep 17 00:00:00 2001 From: Christophe Rhodes Date: Sun, 3 Jun 2007 18:20:08 +0000 Subject: [PATCH] 1.0.6.17: Housekeeping from specializer changes Comments and documentation only. --- doc/manual/beyond-ansi.texinfo | 46 ++++++++++++++++++++++++++++++++++++++++ src/pcl/dfun.lisp | 8 +++++++ version.lisp-expr | 2 +- 3 files changed, 55 insertions(+), 1 deletion(-) diff --git a/doc/manual/beyond-ansi.texinfo b/doc/manual/beyond-ansi.texinfo index 2fc20c8..2bb0ec6 100644 --- a/doc/manual/beyond-ansi.texinfo +++ b/doc/manual/beyond-ansi.texinfo @@ -199,6 +199,52 @@ states that any class found by @code{find-class}, no matter what its @end itemize +In addition, SBCL supports extensions to the Metaobject protocol from +AMOP; at present, they are: + +@itemize + +@item +@findex defmethod +@findex find-class +@findex intern-eql-specializer +@findex sb-mop:intern-eql-specializer +@findex make-method-specializers-form +@findex sb-pcl:make-method-specializers-form +@findex make-method-lambda +@findex sb-mop:make-method-lambda +compile-time support for generating specializer metaobjects from +specializer names in @code{defmethod} forms is provided by the +@code{make-method-specializers-form} function, which returns a form +which, when evaluated in the lexical environment of the +@code{defmethod}, returns a list of specializer metaobjects. This +operator suffers from similar restrictions to those affecting +@code{make-method-lambda}, namely that the generic function must be +defined when the @code{defmethod} form is expanded, so that the +correct method of @code{make-method-specializers-form} is invoked. +The system-provided method on @code{make-method-specializers-form} +generates a call to @code{find-class} for each symbol specializer +name, and a call to @code{intern-eql-specializer} for each @code{(eql +@var{x})} specializer name. + +@item +@findex find-method +@findex parse-specializer-using-class +@findex unparse-specializer-using-class +@findex sb-pcl:parse-specializer-using-class +@findex sb-pcl:unparse-specializer-using-class +run-time support for converting between specializer names and +specializer metaobjects, mostly for the purposes of +@code{find-method}, is provided by +@code{parse-specializer-using-class} and +@code{unparse-specializer-using-class}, which dispatch on their first +argument, the generic function associated with a method with the given +specializer. The system-provided methods on those methods convert +between classes and proper names and between lists of the form +@code{(eql @var{x})} and interned eql specializer objects. + +@end itemize + @node Support For Unix @comment node-name, next, previous, up @section Support For Unix diff --git a/src/pcl/dfun.lisp b/src/pcl/dfun.lisp index 8f0ca1a..5ed2026 100644 --- a/src/pcl/dfun.lisp +++ b/src/pcl/dfun.lisp @@ -1416,9 +1416,17 @@ Except see also BREAK-VICIOUS-METACIRCLE. -- CSR, 2003-05-28 (t specl2))) (class-eq (case (car type2) (eql specl2) + ;; FIXME: This says that all CLASS-EQ + ;; specializers are equally specific, which + ;; is fair enough because only one CLASS-EQ + ;; specializer can ever be appliable. If + ;; ORDER-SPECIALIZERS should only ever be + ;; called on specializers from applicable + ;; methods, we could replace this with a BUG. (class-eq nil) (class type1))) (eql (case (car type2) + ;; similarly. (eql nil) (t specl1)))))))) diff --git a/version.lisp-expr b/version.lisp-expr index 818f8b5..ed6ea52 100644 --- a/version.lisp-expr +++ b/version.lisp-expr @@ -17,4 +17,4 @@ ;;; checkins which aren't released. (And occasionally for internal ;;; versions, especially for internal versions off the main CVS ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) -"1.0.6.16" +"1.0.6.17" -- 1.7.10.4