figures

[paper-els-specializers.git] / els-specializers.org

diff --git a/els-specializers.org b/els-specializers.org
index 714abb686cab9a1cced39f5589e717b506972733..74b26499fd74b009089f55494e846e088aef30f5 100644 (file)
--- a/els-specializers.org
+++ b/els-specializers.org
@@ -81,6 +81,11 @@ efficient.
   incorporating substantial fractions of the Metaobject Protocol as
   described.
 
+  #+CAPTION:    MOP Design Space
+  #+LABEL:      fig:mopdesign
+  #+ATTR_LATEX: width=\linewidth float
+  [[file:figures/mop-design-space.pdf]]
+
   Although it has stood the test of time, the CLOS MOP is neither
   without issues (e.g. semantic problems with =make-method-lambda=
   \cite{Costanza.Herzeel:2008}; useful functions such as
@@ -89,12 +94,16 @@ efficient.
   implement all conceivable variations of object-oriented behaviour.
   While metaprogramming offers some possibilities for customization of
   the object system behaviour, those possibilities cannot extend
-  arbitrarily in all directions.  There is still an expectation that
-  functionality is implemented with methods on generic functions,
-  acting on objects with slots; it is not possible, for example, to
-  transparently implement support for “message not understood” as in
-  the message-passing paradigm, because the analogue of messages
-  (generic functions) need to be defined before they are used.
+  arbitrarily in all directions (conceptually, if a given object
+  system is a point in design space, then a MOP for that object system
+  allows exploration of a region of design space around that point;
+  see figure \ref{fig:mopdesign}).  In the case of the CLOS MOP, there is
+  still an expectation that functionality is implemented with methods
+  on generic functions, acting on objects with slots; it is not
+  possible, for example, to transparently implement support for
+  “message not understood” as in the message-passing paradigm, because
+  the analogue of messages (generic functions) need to be defined
+  before they are used.
 
   Nevertheless, the MOP is flexible, and is used for a number of
   things, including: documentation generation (where introspection in
@@ -104,13 +113,6 @@ efficient.
   symbols); and programmatic construction of metaobjects, for example
   for IDL compilers and model transformations.
 
-  [ XXX: A picture on MOP flexibility here would be good; I have in my mind
-  one where an object system is a point and the MOP opens up a blob
-  around that point, and I'm sure I've seen it somewhere but I can't
-  remember where.  Alternatively, there's Kiczales et al "MOPs: why we
-  want them and what else they can do", fig. 2 ]
-  [AMOP, page 5] paints that picture, but again, only using words :)
-
   One area of functionality where there is scope for customization by
   the metaprogrammer is in the mechanics and semantics of method
   applicability and dispatch.  While in principle AMOP allows
@@ -143,8 +145,8 @@ efficient.
 
   #+CAPTION:    Dispatch Comparison
   #+LABEL:      fig:dispatch
-  #+ATTR_LATEX: width=0.9\linewidth float
-  [[file:figures/dispatch-comparison.pdf]]
+  #+ATTR_LATEX: width=\linewidth float
+  [[file:figures/dispatch-relationships.pdf]]
 
   The remaining sections in this paper can be read in any order.  We
   give some motivating examples in section [[#Examples]], including
@@ -651,8 +653,10 @@ unbound variables.
     required arguments in a list to use as a key in an =equal=
     hash-table.
 
-    [XXX could we actually compute a suitable hash key using the
+#+begin_comment
+    [could we actually compute a suitable hash key using the
     generalizer's class name and initargs?]
+#+end_comment
 
 *** COMMENT
     - [X] =generalizer-of-using-class= (NB class of gf not class of object)