figures

OK, give up on finding where I saw the MOP design space figure and
make one.

diff --git a/dispatch-relationships.tikz b/dispatch-relationships.tikz
deleted file mode 100644 (file)
index 18f774f..0000000
--- a/dispatch-relationships.tikz
+++ /dev/null
@@ -1,33 +0,0 @@
-\documentclass{article}
-
-\usepackage{tikz}
-\usetikzlibrary{shapes.geometric}
-\usetikzlibrary{arrows}
-
-\begin{document}
-
-\begin{tikzpicture}
-  \begin{scope}[minimum width=8em,minimum height=3ex]
-  \node[draw,rectangle] (eql) at (0,0) {\texttt{eql-specializer}};
-  \node[draw,rectangle] (class) at (1,2) {\texttt{class}};
-  \node[draw,rectangle] (specializer) at (0.5,6) {\texttt{specializer}};
-  \node[draw,ellipse] (argument) at (7,2) {\textit{argument}};
-
-  \node[draw,red,ellipse] (generalizer) at (7,4) {\textit{\color{red}generalizer}};
-  \node[draw,red,rectangle] (genspec) at (2,4) {\texttt{\color{red}gen.-spec.}};
-  \end{scope}
-
-  \draw[->,>=open triangle 60] (eql.168) |- (specializer);
-  \draw[->,>=open triangle 60] (class.160) -- (class.160 |- specializer.south);
-  \draw[->,>=open triangle 60,red] (genspec.150) -- (genspec.150 |- specializer.south);
-
-  \draw[dashed] (argument.south) |- node[right,near start] {\texttt{eql}} node[below,near end] {\texttt{eql-specializer-object}} (eql.east);
-  \draw[dashed] (argument.west) -- node[below] {\texttt{typep}} node[above] {\texttt{class-of}} (class.east);
-  \draw[red] (argument.north) -- node[right] {\texttt{\color{red}generalizer-of}} (generalizer.south);
-  \draw[red] (generalizer.west) -- node[above] (sagp) {\texttt{\color{red}s-a-g-p}} (genspec.east);
-  \node (specaccgenp) at (6,5.5) {\texttt{\footnotesize{\color{red}specializer-accepts-generalizer-p}}};
-  \draw[red,dotted] (sagp) -- (specaccgenp);
-
-\end{tikzpicture}
-
-\end{document}
\ No newline at end of file

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.
 
   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
   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
   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
 
   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.
 
   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
   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
 
   #+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
 
   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.
 
     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?]
     generalizer's class name and initargs?]

+#+end_comment

 
 *** COMMENT
     - [X] =generalizer-of-using-class= (NB class of gf not class of object)
 
 *** COMMENT
     - [X] =generalizer-of-using-class= (NB class of gf not class of object)

diff --git a/figures/dispatch-relationships.pdf b/figures/dispatch-relationships.pdf
new file mode 100644 (file)
index 0000000..f90eb1a
Binary files /dev/null and b/figures/dispatch-relationships.pdf differ

diff --git a/figures/dispatch-relationships.tikz b/figures/dispatch-relationships.tikz
new file mode 100644 (file)
index 0000000..db30ab9
--- /dev/null
+++ b/figures/dispatch-relationships.tikz
@@ -0,0 +1,33 @@
+\documentclass{standalone}
+
+\usepackage{tikz}
+\usetikzlibrary{shapes.geometric}
+\usetikzlibrary{arrows}
+
+\begin{document}
+
+\begin{tikzpicture}
+  \begin{scope}[minimum width=8em,minimum height=3ex]
+  \node[draw,rectangle] (eql) at (0,0) {\texttt{eql-specializer}};
+  \node[draw,rectangle] (class) at (1,2) {\texttt{class}};
+  \node[draw,rectangle] (specializer) at (0.5,6) {\texttt{specializer}};
+  \node[draw,ellipse] (argument) at (7,2) {\textit{argument}};
+
+  \node[draw,red,ellipse] (generalizer) at (7,4) {\textit{\color{red}generalizer}};
+  \node[draw,red,rectangle] (genspec) at (2,4) {\texttt{\color{red}gen.-spec.}};
+  \end{scope}
+
+  \draw[->,>=open triangle 60] (eql.168) |- (specializer);
+  \draw[->,>=open triangle 60] (class.160) -- (class.160 |- specializer.south);
+  \draw[->,>=open triangle 60,red] (genspec.150) -- (genspec.150 |- specializer.south);
+
+  \draw[dashed] (argument.south) |- node[right,near start] {\texttt{eql}} node[below,near end] {\texttt{eql-specializer-object}} (eql.east);
+  \draw[dashed] (argument.west) -- node[below] {\texttt{subtypep}} node[above] {\texttt{class-of}} (class.east);
+  \draw[red] (argument.north) -- node[right] {\texttt{\color{red}generalizer-of}} (generalizer.south);
+  \draw[red] (generalizer.west) -- node[above] (sagp) {\texttt{\color{red}s-a-g-p}} (genspec.east);
+  \node (specaccgenp) at (6,5.5) {\texttt{\footnotesize{\color{red}specializer-accepts-generalizer-p}}};
+  \draw[red,dotted] (sagp) -- (specaccgenp);
+
+\end{tikzpicture}
+
+\end{document}
\ No newline at end of file

diff --git a/figures/mop-design-space.pdf b/figures/mop-design-space.pdf
new file mode 100644 (file)
index 0000000..445097f
Binary files /dev/null and b/figures/mop-design-space.pdf differ

diff --git a/figures/mop-design-space.tikz b/figures/mop-design-space.tikz
new file mode 100644 (file)
index 0000000..d99a47b
--- /dev/null
+++ b/figures/mop-design-space.tikz
@@ -0,0 +1,24 @@
+\documentclass{standalone}
+
+\usepackage{tikz}
+\usetikzlibrary{shapes.symbols}
+\usetikzlibrary{arrows}
+\usetikzlibrary{calc}
+
+\begin{document}
+
+\begin{tikzpicture}[>=stealth]
+  \draw [->] (0,0) -- (0,5);
+  \draw [->] (0,0) -- (5,0);
+  \draw [->] (0,0) -- (0,0,5);
+
+  \node[draw,red,cloud,minimum height=2cm,minimum width=2cm] (mop) at (3,4,3) {$\color{black}\bullet$};
+
+  \node (os) at (2.5,2,3) {object system};
+  \draw (os) -- (mop.center);
+
+  \node[red] (mspace) at (5,6,3) {MOP space};
+  \draw[red] (mspace) -- (mop);
+\end{tikzpicture}
+
+\end{document}
\ No newline at end of file