Paepke; AMOP?]. XXX include typical examples of MOP: object
persistence; maybe ref. Kizcales "MOPs: why we want them and what
else they can do"? (Fig. 2 in that is good) ORMs; sparse slots.
+ jmoringe:
+ + introspection, e.g. documentation generation
+ + programmatic construction of classes and generic functions
+ e.g. for IDL compilers, model transformations
One area of functionality where there is scope for customization by
the metaprogrammer is in the mechanics and semantics of method
practice implementation support for this was weak until relatively
recently (ref. closer, also check how ContextL and filtered dispatch
are implemented).
+ jmoringe: filtered dispatch uses a custom method combination, i
+ think
Another potential mechanism for customizing dispatch is implicit in
the class structure defined by AMOP: standard specializer objects
(ahem) the return value of =class-of=, and allows the metaprogrammer
to hook into cacheing schemes to avoid needless recomputation of
effective methods for sufficiently similar generic function
- arguments.
+ arguments (See Figure\nbsp\ref{fig:dispatch}).
+
+ #+CAPTION: Dispatch Comparison
+ #+LABEL: fig:dispatch
+ #+ATTR_LATEX: width=0.9\linewidth float
+ [[file:figures/dispatch-comparison.pdf]]
The remaining sections in this paper can be read in any order. We
give some motivating examples in section XX, including
(defmethod specializer-accepts-p ((s cons-specializer) o)
(and (consp o) (eql (car o) (%car s))))
-#| less interesting methods elided |#
+#| less interesting methods elided: jmoringe: (un)parsing, specializer<?, more? |#
#| XXX insert motivating example from Newton/Rhodes here |#
#+end_src
specializer could be applicable to any given argument)
Also of interest: note that we can have these
- specializer/generalizers handle arbitrary objects: the string and
- tbnl:request methods are independent of each other; this
+ specializer/generalizers handle arbitrary objects: the =string= and
+ =tbnl:request= methods are independent of each other; this
generalizes to dealing with multiple web server libraries.
+
+ jmoringe: the name =accept-specializer=, while sensible, may
+ confusing in this context because "accept" occurs as part of the
+ protocol with a different semantic.
+
#+begin_src lisp
(defclass accept-specializer (extended-specializer)
((media-type :initarg :media-type :reader media-type)))
(next :initarg :next :reader next)))
(defmethod generalizer-equal-hash-key
((gf accept-generic-function) (g accept-generalizer))
- `(accept-generalizer ,(header g)))
+ `(accept-generalizer ,(header g)))
(defmethod specializer-accepts-generalizer-p ((gf accept-generic-function) (s acc
ept-specializer) (generalizer accept-generalizer))
(values (q (media-type s) (tree generalizer)) t))
(defmethod specializer-accepts-p ((s accept-specializer) (string string))
(q (media-type s) (parse-accept-string string)))
#+end_src
+
+ jmoringe: The role of =accept-generalizer.tree= and the =q=
+ function are hard to understand and may require some
+ explanation. However, the example with its distinct, asymmetric
+ specializers/generalizers, =accept-generalizer.next= and
+ =specializer<= is likely worth it.
+
** Pattern / xpattern / regex / optima
Here's the /really/ interesting bit, but on the other hand we're
probably going to run out of space, and the full description of
- these is going to take us into make-method-lambda territory. A
- second paper? Future work? It would be really nice to put a
- marker in the sand.
+ these is going to take us into =make-method-lambda= territory.
+ A second paper? Future work?
* Protocol
** Generalizer
- [ ] =generalizer-of-using-class= (NB class of gf not class of object)
- [ ] =specializer-accepts-generalizer-p=
- [ ] =specializer-accepts-p=
- [ ] =specializer<=
+ jmoringe: If I remember correctly, closette has
+ =method-more-specific-p= should we aim for parity with that and
+ use =specializer-more-specific-p=? The downside would be that
+ =-p= indicates a Boolean return value which is not the case here.
** Full protocol
Description and specification left for reasons of space (we'll see?)
- [ ] =same-specializer-p=
- [ ] =parse/unparse-specializer-using-class=
- [ ] =make-method-specializers-form=
+ - [ ] jmoringe: In an email, I suggested
+ =make-specializer-form-using-class=:
+
+ #+begin_quote
+ Could we change =make-method-specializers-form='s default
+ behaviour to call a new generic function
+ #+begin_src
+ make-specializer-form-using-class gf method name env
+ #+end_src
+ with builtin methods on =sb-mop:specializer=, =symbol=, =cons= (for
+ eql-specializers)? This would make it unnecessary to repeat
+ boilerplate along the lines of
+ #+begin_src lisp
+ (flet ((make-parse-form (name)
+ (if <name-is-interesting>
+ <handle-interesting-specializer>
+ <repeat-handling-of-standard-specializers>)))
+ `(list ,@(mapcar #'make-parse-form specializer-names)))
+ #+end_src
+ for each generic function class.
+ #+end_quote
- [ ] =make-method-lambda= revision (use environment arg?)
+
+ jmoringe: would only be relevant for pattern dispatch, right? I
+ think, we didn't finish the discussion regarding special
+ variables vs. environment vs. new protocol function
* Related Work
- [ ] Newton/Rhodes
- [ ] filtered dispatch
projects / paper-els-specializers.git / blobdiff