From 5aaf0709e635ace2f2db4048fbf8fd2756724cc3 Mon Sep 17 00:00:00 2001 From: Neil Jerram Date: Sat, 25 Sep 2010 17:27:14 +0100 Subject: [PATCH] Edit text about the MOP * doc/ref/goops.texi (The Metaobject Protocol, Metaobjects and the Metaobject Protocol): Minor edits. --- doc/ref/goops.texi | 73 ++++++++++++++++++++-------------------------- 1 file changed, 32 insertions(+), 41 deletions(-) diff --git a/doc/ref/goops.texi b/doc/ref/goops.texi index 34658758e..ebb2fd712 100644 --- a/doc/ref/goops.texi +++ b/doc/ref/goops.texi @@ -2156,29 +2156,21 @@ as the Guile primitive @code{write} and @code{display} functions. @node The Metaobject Protocol @section The Metaobject Protocol -GOOPS is based on a ``metaobject protocol'' derived from the ones used -in CLOS (the Common Lisp Object System), tiny-clos (a small Scheme -implementation of a subset of CLOS functionality) and STKlos. +GOOPS is based on a ``metaobject protocol'' (aka ``MOP'') derived from +the ones used in CLOS (the Common Lisp Object System), tiny-clos (a +small Scheme implementation of a subset of CLOS functionality) and +STKlos. GOOPS can be used by application authors at a basic level without any -need to understand what the metaobject protocol (aka ``MOP'') is and how -it works. On the other hand, the MOP underlies even the customizations -that application authors are likely to make use of very quickly --- such -as defining an @code{initialize} method to customize the initialization -of instances of an application-defined class --- and an understanding of -the MOP makes it much easier to explain such customizations in a precise -way. And in the long run, understanding the MOP is the key both to +need to understand what the MOP is and how it works. On the other hand, +the MOP underlies even very simple customizations --- such as defining +an @code{initialize} method to customize the initialization of instances +of an application-defined class --- and an understanding of the MOP +makes it much easier to explain such customizations in a precise way. +And in the long run, understanding the MOP is the key both to understanding GOOPS at a deeper level and to taking full advantage of GOOPS' power, by customizing the behaviour of GOOPS itself. -These introductory remarks continue with a few words about metaobjects -and the MOP. - -In general, this reference manual assumes familiarity with standard -object oriented concepts and terminology. However, some of the terms -used in GOOPS are less well known, so the Terminology subsubsection -provides definitions for these terms. - @menu * Metaobjects and the Metaobject Protocol:: * Terminology:: @@ -2193,10 +2185,10 @@ provides definitions for these terms. @node Metaobjects and the Metaobject Protocol @subsection Metaobjects and the Metaobject Protocol -The conceptual building blocks of GOOPS are classes, slot definitions, -instances, generic functions and methods. A class is a grouping of -inheritance relations and slot definitions. An instance is an object -with slots that are allocated following the rules implied by its class's +The building blocks of GOOPS are classes, slot definitions, instances, +generic functions and methods. A class is a grouping of inheritance +relations and slot definitions. An instance is an object with slots +that are allocated following the rules implied by its class's superclasses and slot definitions. A generic function is a collection of methods and rules for determining which of those methods to apply when the generic function is invoked. A method is a procedure and a set @@ -2238,9 +2230,9 @@ of steps is as follows. @itemize @bullet @item @code{define-class} uses @code{make} to make a new instance of the -@code{}, passing as initialization arguments the superclasses, -slot definitions and class options that were specified in the -@code{define-class} form. +@code{} class, passing as initialization arguments the +superclasses, slot definitions and class options that were specified in +the @code{define-class} form. @item @code{make} allocates memory for the new instance, and then invokes the @@ -2282,23 +2274,22 @@ of that class. Such is the power of the MOP. Note that @code{initialize} is just one of a large number of generic functions that can be customized to modify the behaviour of application objects and classes and of GOOPS itself. -Each subsequent section of the reference manual covers a particular area -of GOOPS functionality, and describes the generic functions that are -relevant for customization of that area. +Each following section covers a particular area of GOOPS functionality, +and describes the generic functions that are relevant for customization +of that area. -We conclude this subsubsection by emphasizing a point that may seem -obvious, but contrasts with the corresponding situation in some other -MOP implementations, such as CLOS. The point is simply that an -identifier which represents a GOOPS class or generic function is a -variable with a first-class value, the value being an instance of class -@code{} or @code{}. (In CLOS, on the other hand, a -class identifier is a symbol that indexes the corresponding class -metaobject in a separate namespace for classes.) This is, of course, -simply an extension of the tendency in Scheme to avoid the unnecessary -use of, on the one hand, syntactic forms that require unevaluated -arguments and, on the other, separate identifier namespaces (e.g. for -class names), but it is worth noting that GOOPS conforms fully to this -Schemely principle. +We conclude these remarks by emphasizing a point that may seem obvious, +but contrasts with the corresponding situation in some other MOP +implementations, such as CLOS. The point is simply that an identifier +which represents a GOOPS class or generic function is a variable with a +first-class value, the value being an instance of class @code{} +or @code{}. (In CLOS, on the other hand, a class identifier is +a symbol that indexes the corresponding class metaobject in a separate +namespace for classes.) This is, of course, simply an extension of the +tendency in Scheme to avoid the unnecessary use of, on the one hand, +syntactic forms that require unevaluated arguments and, on the other, +separate identifier namespaces (e.g. for class names), but it is worth +noting that GOOPS conforms fully to this Schemely principle. @node Terminology @subsection Terminology