2 @c This is part of the GNU Guile Reference Manual.
3 @c Copyright (C) 2008, 2009
4 @c Free Software Foundation, Inc.
5 @c See the file guile.texi for copying conditions.
18 @goops{} is the object oriented extension to @guile{}. Its
19 implementation is derived from @w{STk-3.99.3} by Erick Gallesio and
20 version 1.3 of Gregor Kiczales @cite{Tiny-Clos}. It is very close in
21 spirit to CLOS, the Common Lisp Object System (@cite{CLtL2}) but is
22 adapted for the Scheme language. While GOOPS is not compatible with any
23 of these systems, GOOPS contains a compatibility module which allows for
24 execution of STKlos programs.
26 Briefly stated, the @goops{} extension gives the user a full object
27 oriented system with multiple inheritance and generic functions with
28 multi-method dispatch. Furthermore, the implementation relies on a true
29 meta object protocol, in the spirit of the one defined for CLOS
30 (@cite{Gregor Kiczales: A Metaobject Protocol}).
40 @section Getting Started
42 To start using GOOPS, load the @code{(oop goops)} module:
45 (use-modules (oop goops))
48 We're now ready to try some basic GOOPS functionality.
52 * User-defined types::
53 * Asking for the type of an object::
61 (define-method (+ (x <string>) (y <string>))
65 (+ "abc" "de") --> "abcde"
69 @node User-defined types
70 @subsection User-defined types
73 (define-class <2D-vector> ()
74 (x #:init-value 0 #:accessor x-component #:init-keyword #:x)
75 (y #:init-value 0 #:accessor y-component #:init-keyword #:y))
78 (use-modules (ice-9 format))
80 (define-method (write (obj <2D-vector>) port)
81 (display (format #f "<~S, ~S>" (x-component obj) (y-component obj))
84 (define v (make <2D-vector> #:x 3 #:y 4))
90 (define-method (+ (x <2D-vector>) (y <2D-vector>))
92 #:x (+ (x-component x) (x-component y))
93 #:y (+ (y-component x) (y-component y))))
99 @node Asking for the type of an object
103 (class-of v) --> #<<class> <2D-vector> 40241ac0>
104 <2D-vector> --> #<<class> <2D-vector> 40241ac0>
105 (class-of 1) --> #<<class> <integer> 401b2a98>
106 <integer> --> #<<class> <integer> 401b2a98>
108 (is-a? v <2D-vector>) --> #t
113 @include goops-tutorial.texi
115 @node Reference Manual
116 @section Reference Manual
118 This chapter is the GOOPS reference manual. It aims to describe all the
119 syntax, procedures, options and associated concepts that a typical
120 application author would need to understand in order to use GOOPS
121 effectively in their application. It also describes what is meant by
122 the GOOPS ``metaobject protocol'' (aka ``MOP''), and indicates how
123 authors can use the metaobject protocol to customize the behaviour of
126 For a detailed specification of the GOOPS metaobject protocol, see
127 @ref{MOP Specification}.
130 * Introductory Remarks::
131 * Defining New Classes::
132 * Creating Instances::
134 * Creating Generic Functions::
135 * Adding Methods to Generic Functions::
136 * Invoking Generic Functions::
137 * Redefining a Class::
138 * Changing the Class of an Instance::
140 * Miscellaneous Functions::
143 @node Introductory Remarks
144 @subsection Introductory Remarks
146 GOOPS is an object-oriented programming system based on a ``metaobject
147 protocol'' derived from the ones used in CLOS (the Common Lisp Object
148 System), tiny-clos (a small Scheme implementation of a subset of CLOS
149 functionality) and STKlos.
151 GOOPS can be used by application authors at a basic level without any
152 need to understand what the metaobject protocol (aka ``MOP'') is and how
153 it works. On the other hand, the MOP underlies even the customizations
154 that application authors are likely to make use of very quickly --- such
155 as defining an @code{initialize} method to customize the initialization
156 of instances of an application-defined class --- and an understanding of
157 the MOP makes it much easier to explain such customizations in a precise
158 way. And in the long run, understanding the MOP is the key both to
159 understanding GOOPS at a deeper level and to taking full advantage of
160 GOOPS' power, by customizing the behaviour of GOOPS itself.
162 Each of the following sections of the reference manual is arranged
163 such that the most basic usage is introduced first, and then subsequent
164 subsubsections discuss the related internal functions and metaobject
165 protocols, finishing with a description of how to customize that area of
168 These introductory remarks continue with a few words about metaobjects
169 and the MOP. Readers who do not want to be bothered yet with the MOP
170 and customization could safely skip this subsubsection on a first reading,
171 and should correspondingly skip subsequent subsubsections that are
172 concerned with internals and customization.
174 In general, this reference manual assumes familiarity with standard
175 object oriented concepts and terminology. However, some of the terms
176 used in GOOPS are less well known, so the Terminology subsubsection
177 provides definitions for these terms.
180 * Metaobjects and the Metaobject Protocol::
184 @node Metaobjects and the Metaobject Protocol
185 @subsubsection Metaobjects and the Metaobject Protocol
187 The conceptual building blocks of GOOPS are classes, slot definitions,
188 instances, generic functions and methods. A class is a grouping of
189 inheritance relations and slot definitions. An instance is an object
190 with slots that are allocated following the rules implied by its class's
191 superclasses and slot definitions. A generic function is a collection
192 of methods and rules for determining which of those methods to apply
193 when the generic function is invoked. A method is a procedure and a set
194 of specializers that specify the type of arguments to which the
195 procedure is applicable.
197 Of these entities, GOOPS represents classes, generic functions and
198 methods as ``metaobjects''. In other words, the values in a GOOPS
199 program that describe classes, generic functions and methods, are
200 themselves instances (or ``objects'') of special GOOPS classes that
201 encapsulate the behaviour, respectively, of classes, generic functions,
204 (The other two entities are slot definitions and instances. Slot
205 definitions are not strictly instances, but every slot definition is
206 associated with a GOOPS class that specifies the behaviour of the slot
207 as regards accessibility and protection from garbage collection.
208 Instances are of course objects in the usual sense, and there is no
209 benefit from thinking of them as metaobjects.)
211 The ``metaobject protocol'' (aka ``MOP'') is the specification of the
212 generic functions which determine the behaviour of these metaobjects and
213 the circumstances in which these generic functions are invoked.
215 For a concrete example of what this means, consider how GOOPS calculates
216 the set of slots for a class that is being defined using
217 @code{define-class}. The desired set of slots is the union of the new
218 class's direct slots and the slots of all its superclasses. But
219 @code{define-class} itself does not perform this calculation. Instead,
220 there is a method of the @code{initialize} generic function that is
221 specialized for instances of type @code{<class>}, and it is this method
222 that performs the slot calculation.
224 @code{initialize} is a generic function which GOOPS calls whenever a new
225 instance is created, immediately after allocating memory for a new
226 instance, in order to initialize the new instance's slots. The sequence
227 of steps is as follows.
231 @code{define-class} uses @code{make} to make a new instance of the
232 @code{<class>}, passing as initialization arguments the superclasses,
233 slot definitions and class options that were specified in the
234 @code{define-class} form.
237 @code{make} allocates memory for the new instance, and then invokes the
238 @code{initialize} generic function to initialize the new instance's
242 The @code{initialize} generic function applies the method that is
243 specialized for instances of type @code{<class>}, and this method
244 performs the slot calculation.
247 In other words, rather than being hardcoded in @code{define-class}, the
248 behaviour of class definition is encapsulated by generic function
249 methods that are specialized for the class @code{<class>}.
251 It is possible to create a new class that inherits from @code{<class>},
252 which is called a ``metaclass'', and to write a new @code{initialize}
253 method that is specialized for instances of the new metaclass. Then, if
254 the @code{define-class} form includes a @code{#:metaclass} class option
255 whose value is the new metaclass, the class that is defined by the
256 @code{define-class} form will be an instance of the new metaclass rather
257 than of the default @code{<class>}, and will be defined in accordance
258 with the new @code{initialize} method. Thus the default slot
259 calculation, as well as any other aspect of the new class's relationship
260 with its superclasses, can be modified or overridden.
262 In a similar way, the behaviour of generic functions can be modified or
263 overridden by creating a new class that inherits from the standard
264 generic function class @code{<generic>}, writing appropriate methods
265 that are specialized to the new class, and creating new generic
266 functions that are instances of the new class.
268 The same is true for method metaobjects. And the same basic mechanism
269 allows the application class author to write an @code{initialize} method
270 that is specialized to their application class, to initialize instances
273 Such is the power of the MOP. Note that @code{initialize} is just one
274 of a large number of generic functions that can be customized to modify
275 the behaviour of application objects and classes and of GOOPS itself.
276 Each subsequent section of the reference manual covers a particular area
277 of GOOPS functionality, and describes the generic functions that are
278 relevant for customization of that area.
280 We conclude this subsubsection by emphasizing a point that may seem
281 obvious, but contrasts with the corresponding situation in some other
282 MOP implementations, such as CLOS. The point is simply that an
283 identifier which represents a GOOPS class or generic function is a
284 variable with a first-class value, the value being an instance of class
285 @code{<class>} or @code{<generic>}. (In CLOS, on the other hand, a
286 class identifier is a symbol that indexes the corresponding class
287 metaobject in a separate namespace for classes.) This is, of course,
288 simply an extension of the tendency in Scheme to avoid the unnecessary
289 use of, on the one hand, syntactic forms that require unevaluated
290 arguments and, on the other, separate identifier namespaces (e.g. for
291 class names), but it is worth noting that GOOPS conforms fully to this
295 @subsubsection Terminology
297 It is assumed that the reader is already familiar with standard object
298 orientation concepts such as classes, objects/instances,
299 inheritance/subclassing, generic functions and methods, encapsulation
302 This section explains some of the less well known concepts and
303 terminology that GOOPS uses, which are assumed by the following sections
304 of the reference manual.
306 @subsubheading Metaclass
308 A @dfn{metaclass} is the class of an object which represents a GOOPS
309 class. Put more succinctly, a metaclass is a class's class.
311 Most GOOPS classes have the metaclass @code{<class>} and, by default,
312 any new class that is created using @code{define-class} has the
313 metaclass @code{<class>}.
315 But what does this really mean? To find out, let's look in more detail
316 at what happens when a new class is created using @code{define-class}:
319 (define-class <my-class> (<object>) . slots)
322 GOOPS actually expands the @code{define-class} form to something like
326 (define <my-class> (class (<object>) . slots))
333 (make <class> #:supers (list <object>) #:slots slots))
336 In other words, the value of @code{<my-class>} is in fact an instance of
337 the class @code{<class>} with slot values specifying the superclasses
338 and slot definitions for the class @code{<my-class>}. (@code{#:supers}
339 and @code{#:slots} are initialization keywords for the @code{dsupers}
340 and @code{dslots} slots of the @code{<class>} class.)
342 In order to take advantage of the full power of the GOOPS metaobject
343 protocol (@pxref{MOP Specification}), it is sometimes desirable to
344 create a new class with a metaclass other than the default
345 @code{<class>}. This is done by writing:
348 (define-class <my-class2> (<object>)
350 #:metaclass <my-metaclass>)
353 GOOPS expands this to something like:
357 (make <my-metaclass> #:supers (list <object>) #:slots slots))
360 In this case, the value of @code{<my-class2>} is an instance of the more
361 specialized class @code{<my-metaclass>}. Note that
362 @code{<my-metaclass>} itself must previously have been defined as a
363 subclass of @code{<class>}. For a full discussion of when and how it is
364 useful to define new metaclasses, see @ref{MOP Specification}.
366 Now let's make an instance of @code{<my-class2>}:
369 (define my-object (make <my-class2> ...))
372 All of the following statements are correct expressions of the
373 relationships between @code{my-object}, @code{<my-class2>},
374 @code{<my-metaclass>} and @code{<class>}.
378 @code{my-object} is an instance of the class @code{<my-class2>}.
381 @code{<my-class2>} is an instance of the class @code{<my-metaclass>}.
384 @code{<my-metaclass>} is an instance of the class @code{<class>}.
387 The class of @code{my-object} is @code{<my-class2>}.
390 The metaclass of @code{my-object} is @code{<my-metaclass>}.
393 The class of @code{<my-class2>} is @code{<my-metaclass>}.
396 The metaclass of @code{<my-class2>} is @code{<class>}.
399 The class of @code{<my-metaclass>} is @code{<class>}.
402 The metaclass of @code{<my-metaclass>} is @code{<class>}.
405 @code{<my-class2>} is not a metaclass, since it is does not inherit from
409 @code{<my-metaclass>} is a metaclass, since it inherits from
413 @subsubheading Class Precedence List
415 The @dfn{class precedence list} of a class is the list of all direct and
416 indirect superclasses of that class, including the class itself.
418 In the absence of multiple inheritance, the class precedence list is
419 ordered straightforwardly, beginning with the class itself and ending
422 For example, given this inheritance hierarchy:
425 (define-class <invertebrate> (<object>) @dots{})
426 (define-class <echinoderm> (<invertebrate>) @dots{})
427 (define-class <starfish> (<echinoderm>) @dots{})
430 the class precedence list of <starfish> would be
433 (<starfish> <echinoderm> <invertebrate> <object> <top>)
436 With multiple inheritance, the algorithm is a little more complicated.
437 A full description is provided by the GOOPS Tutorial: see @ref{Class
440 ``Class precedence list'' is often abbreviated, in documentation and
441 Scheme variable names, to @dfn{cpl}.
443 @subsubheading Accessor
445 An @dfn{accessor} is a generic function with both reference and setter
449 (define-accessor perimeter)
452 Reference methods for an accessor are defined in the same way as generic
456 (define-method (perimeter (s <square>))
457 (* 4 (side-length s)))
460 Setter methods for an accessor are defined by specifying ``(setter
461 <accessor-name>)'' as the first parameter of the @code{define-method}
465 (define-method ((setter perimeter) (s <square>) (n <number>))
466 (set! (side-length s) (/ n 4)))
469 Once an appropriate setter method has been defined in this way, it can
470 be invoked using the generalized @code{set!} syntax, as in:
473 (set! (perimeter s1) 18.3)
476 @node Defining New Classes
477 @subsection Defining New Classes
479 [ *fixme* Somewhere in this manual there needs to be an introductory
480 discussion about GOOPS classes, generic functions and methods, covering
484 how classes encapsulate related items of data in @dfn{slots}
487 why it is that, unlike in C++ and Java, a class does not encapsulate the
488 methods that act upon the class (at least not in the C++/Java sense)
491 how generic functions provide a more general solution that provides for
492 dispatch on all argument types, and avoids idiosyncracies like C++'s
496 how encapsulation in the sense of data- and code-hiding, or of
497 distinguishing interface from implementation, is treated in Guile as an
498 orthogonal concept to object orientation, and is the responsibility of
502 Some of this is covered in the Tutorial chapter, in @ref{Generic
503 functions and methods} - perhaps the best solution would be to expand
504 the discussion there. ]
507 * Basic Class Definition::
510 * Class Definition Internals::
511 * Customizing Class Definition::
512 * STKlos Compatibility::
515 @node Basic Class Definition
516 @subsubsection Basic Class Definition
518 New classes are defined using the @code{define-class} syntax, with
519 arguments that specify the classes that the new class should inherit
520 from, the direct slots of the new class, and any required class options.
522 @deffn syntax define-class name (super @dots{}) slot-definition @dots{} . options
523 Define a class called @var{name} that inherits from @var{super}s, with
524 direct slots defined by @var{slot-definition}s and class options
525 @var{options}. The newly created class is bound to the variable name
526 @var{name} in the current environment.
528 Each @var{slot-definition} is either a symbol that names the slot or a
532 (@var{slot-name-symbol} . @var{slot-options})
535 where @var{slot-name-symbol} is a symbol and @var{slot-options} is a
536 list with an even number of elements. The even-numbered elements of
537 @var{slot-options} (counting from zero) are slot option keywords; the
538 odd-numbered elements are the corresponding values for those keywords.
540 @var{options} is a similarly structured list containing class option
541 keywords and corresponding values.
544 The standard GOOPS class and slot options are described in the following
545 subsubsections: see @ref{Class Options} and @ref{Slot Options}.
547 Example 1. Define a class that combines two pre-existing classes by
548 inheritance but adds no new slots.
551 (define-class <combined> (<tree> <bicycle>))
554 Example 2. Define a @code{regular-polygon} class with slots for side
555 length and number of sides that have default values and can be accessed
556 via the generic functions @code{side-length} and @code{num-sides}.
559 (define-class <regular-polygon> ()
560 (sl #:init-value 1 #:accessor side-length)
561 (ns #:init-value 5 #:accessor num-sides))
564 Example 3. Define a class whose behavior (and that of its instances) is
565 customized via an application-defined metaclass.
568 (define-class <tcpip-fsm> ()
569 (s #:init-value #f #:accessor state)
571 #:metaclass <finite-state-class>)
575 @subsubsection Class Options
577 @deffn {class option} #:metaclass metaclass
578 The @code{#:metaclass} class option specifies the metaclass of the class
579 being defined. @var{metaclass} must be a class that inherits from
580 @code{<class>}. For an introduction to the use of metaclasses, see
581 @ref{Metaobjects and the Metaobject Protocol} and @ref{Terminology}.
583 If the @code{#:metaclass} option is absent, GOOPS reuses or constructs a
584 metaclass for the new class by calling @code{ensure-metaclass}
585 (@pxref{Class Definition Internals,, ensure-metaclass}).
588 @deffn {class option} #:name name
589 The @code{#:name} class option specifies the new class's name. This
590 name is used to identify the class whenever related objects - the class
591 itself, its instances and its subclasses - are printed.
593 If the @code{#:name} option is absent, GOOPS uses the first argument to
594 @code{define-class} as the class name.
597 @deffn {class option} #:environment environment
598 *fixme* Not sure about this one, but I think that the
599 @code{#:environment} option specifies the environment in which the
600 class's getters and setters are computed and evaluated.
602 If the @code{#:environment} option is not specified, the class's
603 environment defaults to the top-level environment in which the
604 @code{define-class} form appears.
608 @subsubsection Slot Options
610 @deffn {slot option} #:allocation allocation
611 The @code{#:allocation} option tells GOOPS how to allocate storage for
612 the slot. Possible values for @var{allocation} are
615 @item @code{#:instance}
617 Indicates that GOOPS should create separate storage for this slot in
618 each new instance of the containing class (and its subclasses).
622 Indicates that GOOPS should create storage for this slot that is shared
623 by all instances of the containing class (and its subclasses). In other
624 words, a slot in class @var{C} with allocation @code{#:class} is shared
625 by all @var{instance}s for which @code{(is-a? @var{instance} @var{c})}.
627 @item @code{#:each-subclass}
629 Indicates that GOOPS should create storage for this slot that is shared
630 by all @emph{direct} instances of the containing class, and that
631 whenever a subclass of the containing class is defined, GOOPS should
632 create a new storage for the slot that is shared by all @emph{direct}
633 instances of the subclass. In other words, a slot with allocation
634 @code{#:each-subclass} is shared by all instances with the same
637 @item @code{#:virtual}
639 Indicates that GOOPS should not allocate storage for this slot. The
640 slot definition must also include the @code{#:slot-ref} and
641 @code{#:slot-set!} options to specify how to reference and set the value
645 The default value is @code{#:instance}.
647 Slot allocation options are processed when defining a new class by the
648 generic function @code{compute-get-n-set}, which is specialized by the
649 class's metaclass. Hence new types of slot allocation can be
650 implemented by defining a new metaclass and a method for
651 @code{compute-get-n-set} that is specialized for the new metaclass. For
652 an example of how to do this, see @ref{Customizing Class Definition}.
655 @deffn {slot option} #:slot-ref getter
656 @deffnx {slot option} #:slot-set! setter
657 The @code{#:slot-ref} and @code{#:slot-set!} options must be specified
658 if the slot allocation is @code{#:virtual}, and are ignored otherwise.
660 @var{getter} should be a closure taking a single @var{instance} parameter
661 that returns the current slot value. @var{setter} should be a closure
662 taking two parameters - @var{instance} and @var{new-val} - that sets the
663 slot value to @var{new-val}.
666 @deffn {slot option} #:getter getter
667 @deffnx {slot option} #:setter setter
668 @deffnx {slot option} #:accessor accessor
669 These options, if present, tell GOOPS to create generic function and
670 method definitions that can be used to get and set the slot value more
671 conveniently than by using @code{slot-ref} and @code{slot-set!}.
673 @var{getter} specifies a generic function to which GOOPS will add a
674 method for getting the slot value. @var{setter} specifies a generic
675 function to which GOOPS will add a method for setting the slot value.
676 @var{accessor} specifies an accessor to which GOOPS will add methods for
677 both getting and setting the slot value.
679 So if a class includes a slot definition like this:
682 (c #:getter get-count #:setter set-count #:accessor count)
685 GOOPS defines generic function methods such that the slot value can be
686 referenced using either the getter or the accessor -
689 (let ((current-count (get-count obj))) @dots{})
690 (let ((current-count (count obj))) @dots{})
693 - and set using either the setter or the accessor -
696 (set-count obj (+ 1 current-count))
697 (set! (count obj) (+ 1 current-count))
704 with an accessor, the slot value is set using the generalized
708 in practice, it is unusual for a slot to use all three of these options:
709 read-only, write-only and read-write slots would typically use only
710 @code{#:getter}, @code{#:setter} and @code{#:accessor} options
714 If the specified names are already bound in the top-level environment to
715 values that cannot be upgraded to generic functions, those values are
716 overwritten during evaluation of the @code{define-class} that contains
717 the slot definition. For details, see @ref{Generic Function Internals,,
721 @deffn {slot option} #:init-value init-value
722 @deffnx {slot option} #:init-form init-form
723 @deffnx {slot option} #:init-thunk init-thunk
724 @deffnx {slot option} #:init-keyword init-keyword
725 These options provide various ways to specify how to initialize the
726 slot's value at instance creation time. @var{init-value} is a fixed
727 value (shared across all new instances of the class).
728 @var{init-thunk} is a procedure of no arguments that is called
729 when a new instance is created and should return the desired initial
730 slot value. @var{init-form} is an unevaluated expression that gets
731 evaluated when a new instance is created and should return the desired
732 initial slot value. @var{init-keyword} is a keyword that can be used
733 to pass an initial slot value to @code{make} when creating a new
736 Note that, since an @code{init-value} value is shared across all
737 instances of a class, you should only use it when the initial value is
738 an immutable value, like a constant. If you want to initialize a slot
739 with a fresh, independently mutable value, you should use
740 @code{init-thunk} or @code{init-form} instead. Consider the following
744 (define-class <chbouib> ()
745 (hashtab #:init-value (make-hash-table)))
749 Here only one hash table is created and all instances of
750 @code{<chbouib>} have their @code{hashtab} slot refer to it. In order
751 to have each instance of @code{<chbouib>} refer to a new hash table, you
752 should instead write:
755 (define-class <chbouib> ()
756 (hashtab #:init-thunk make-hash-table))
763 (define-class <chbouib> ()
764 (hashtab #:init-form (make-hash-table)))
767 If more than one of these options is specified for the same slot, the
768 order of precedence, highest first is
772 @code{#:init-keyword}, if @var{init-keyword} is present in the options
773 passed to @code{make}
776 @code{#:init-thunk}, @code{#:init-form} or @code{#:init-value}.
779 If the slot definition contains more than one initialization option of
780 the same precedence, the later ones are ignored. If a slot is not
781 initialized at all, its value is unbound.
783 In general, slots that are shared between more than one instance are
784 only initialized at new instance creation time if the slot value is
785 unbound at that time. However, if the new instance creation specifies
786 a valid init keyword and value for a shared slot, the slot is
787 re-initialized regardless of its previous value.
789 Note, however, that the power of GOOPS' metaobject protocol means that
790 everything written here may be customized or overridden for particular
791 classes! The slot initializations described here are performed by the least
792 specialized method of the generic function @code{initialize}, whose
796 (define-method (initialize (object <object>) initargs) ...)
799 The initialization of instances of any given class can be customized by
800 defining a @code{initialize} method that is specialized for that class,
801 and the author of the specialized method may decide to call
802 @code{next-method} - which will result in a call to the next less
803 specialized @code{initialize} method - at any point within the
804 specialized code, or maybe not at all. In general, therefore, the
805 initialization mechanisms described here may be modified or overridden by
806 more specialized code, or may not be supported at all for particular
810 @node Class Definition Internals
811 @subsubsection Class Definition Internals
813 Implementation notes: @code{define-class} expands to an expression which
817 checks that it is being evaluated only at top level
820 defines any accessors that are implied by the @var{slot-definition}s
823 uses @code{class} to create the new class (@pxref{Class Definition
827 checks for a previous class definition for @var{name} and, if found,
828 handles the redefinition by invoking @code{class-redefinition}
829 (@pxref{Redefining a Class}).
832 @deffn syntax class name (super @dots{}) slot-definition @dots{} . options
833 Return a newly created class that inherits from @var{super}s, with
834 direct slots defined by @var{slot-definition}s and class options
835 @var{options}. For the format of @var{slot-definition}s and
836 @var{options}, see @ref{Basic Class Definition,, define-class}.
839 Implementation notes: @code{class} expands to an expression which
843 processes the class and slot definition options to check that they are
844 well-formed, to convert the @code{#:init-form} option to an
845 @code{#:init-thunk} option, to supply a default environment parameter
846 (the current top-level environment) and to evaluate all the bits that
850 calls @code{make-class} to create the class with the processed and
851 evaluated parameters.
854 @deffn procedure make-class supers slots . options
855 Return a newly created class that inherits from @var{supers}, with
856 direct slots defined by @var{slots} and class options @var{options}.
857 For the format of @var{slots} and @var{options}, see @ref{Basic Class
858 Definition,, define-class}, except note that for @code{make-class},
859 @var{slots} and @var{options} are separate list parameters: @var{slots}
860 here is a list of slot definitions.
863 Implementation notes: @code{make-class}
867 adds @code{<object>} to the @var{supers} list if @var{supers} is empty
868 or if none of the classes in @var{supers} have @code{<object>} in their
869 class precedence list
872 defaults the @code{#:environment}, @code{#:name} and @code{#:metaclass}
873 options, if they are not specified by @var{options}, to the current
874 top-level environment, the unbound value, and @code{(ensure-metaclass
875 @var{supers})} respectively (@pxref{Class Definition Internals,,
879 checks for duplicate classes in @var{supers} and duplicate slot names in
880 @var{slots}, and signals an error if there are any duplicates
883 calls @code{make}, passing the metaclass as the first parameter and all
884 other parameters as option keywords with values.
887 @deffn procedure ensure-metaclass supers env
888 Return a metaclass suitable for a class that inherits from the list of
889 classes in @var{supers}. The returned metaclass is the union by
890 inheritance of the metaclasses of the classes in @var{supers}.
892 In the simplest case, where all the @var{supers} are straightforward
893 classes with metaclass @code{<class>}, the returned metaclass is just
896 For a more complex example, suppose that @var{supers} contained one
897 class with metaclass @code{<operator-class>} and one with metaclass
898 @code{<foreign-object-class>}. Then the returned metaclass would be a
899 class that inherits from both @code{<operator-class>} and
900 @code{<foreign-object-class>}.
902 If @var{supers} is the empty list, @code{ensure-metaclass} returns the
903 default GOOPS metaclass @code{<class>}.
905 GOOPS keeps a list of the metaclasses created by
906 @code{ensure-metaclass}, so that each required type of metaclass only
907 has to be created once.
909 The @code{env} parameter is ignored.
912 @deffn procedure ensure-metaclass-with-supers meta-supers
913 @code{ensure-metaclass-with-supers} is an internal procedure used by
914 @code{ensure-metaclass} (@pxref{Class Definition Internals,,
915 ensure-metaclass}). It returns a metaclass that is the union by
916 inheritance of the metaclasses in @var{meta-supers}.
919 The internals of @code{make}, which is ultimately used to create the new
920 class object, are described in @ref{Customizing Instance Creation},
921 which covers the creation and initialization of instances in general.
923 @node Customizing Class Definition
924 @subsubsection Customizing Class Definition
926 During the initialization of a new class, GOOPS calls a number of generic
927 functions with the newly allocated class instance as the first
928 argument. Specifically, GOOPS calls the generic function
932 (initialize @var{class} @dots{})
935 where @var{class} is the newly allocated class instance, and the default
936 @code{initialize} method for arguments of type @code{<class>} calls the
941 (compute-cpl @var{class})
944 (compute-slots @var{class})
947 (compute-get-n-set @var{class} @var{slot-def}), for each of the slot
948 definitions returned by @code{compute-slots}
951 (compute-getter-method @var{class} @var{slot-def}), for each of the
952 slot definitions returned by @code{compute-slots} that includes a
953 @code{#:getter} or @code{#:accessor} slot option
956 (compute-setter-method @var{class} @var{slot-def}), for each of the
957 slot definitions returned by @code{compute-slots} that includes a
958 @code{#:setter} or @code{#:accessor} slot option.
961 If the metaclass of the new class is something more specialized than the
962 default @code{<class>}, then the type of @var{class} in the calls above
963 is more specialized than @code{<class>}, and hence it becomes possible
964 to define generic function methods, specialized for the new class's
965 metaclass, that can modify or override the default behaviour of
966 @code{initialize}, @code{compute-cpl} or @code{compute-get-n-set}.
968 @code{compute-cpl} computes the class precedence list (``CPL'') for the
969 new class (@pxref{Class precedence list}), and returns it as a list of
970 class objects. The CPL is important because it defines a superclass
971 ordering that is used, when a generic function is invoked upon an
972 instance of the class, to decide which of the available generic function
973 methods is the most specific. Hence @code{compute-cpl} could be
974 customized in order to modify the CPL ordering algorithm for all classes
975 with a special metaclass.
977 The default CPL algorithm is encapsulated by the @code{compute-std-cpl}
978 procedure, which is in turn called by the default @code{compute-cpl}
981 @deffn procedure compute-std-cpl class
982 Compute and return the class precedence list for @var{class} according
983 to the algorithm described in @ref{Class precedence list}.
986 @code{compute-slots} computes and returns a list of all slot definitions
987 for the new class. By default, this list includes the direct slot
988 definitions from the @code{define-class} form, plus the slot definitions
989 that are inherited from the new class's superclasses. The default
990 @code{compute-slots} method uses the CPL computed by @code{compute-cpl}
991 to calculate this union of slot definitions, with the rule that slots
992 inherited from superclasses are shadowed by direct slots with the same
993 name. One possible reason for customizing @code{compute-slots} would be
994 to implement an alternative resolution strategy for slot name conflicts.
996 @code{compute-get-n-set} computes the low-level closures that will be
997 used to get and set the value of a particular slot, and returns them in
998 a list with two elements.
1000 The closures returned depend on how storage for that slot is allocated.
1001 The standard @code{compute-get-n-set} method, specialized for classes of
1002 type @code{<class>}, handles the standard GOOPS values for the
1003 @code{#:allocation} slot option (@pxref{Slot Options,, allocation}). By
1004 defining a new @code{compute-get-n-set} method for a more specialized
1005 metaclass, it is possible to support new types of slot allocation.
1007 Suppose you wanted to create a large number of instances of some class
1008 with a slot that should be shared between some but not all instances of
1009 that class - say every 10 instances should share the same slot storage.
1010 The following example shows how to implement and use a new type of slot
1011 allocation to do this.
1014 (define-class <batched-allocation-metaclass> (<class>))
1016 (let ((batch-allocation-count 0)
1017 (batch-get-n-set #f))
1018 (define-method (compute-get-n-set
1019 (class <batched-allocation-metaclass>) s)
1020 (case (slot-definition-allocation s)
1022 ;; If we've already used the same slot storage for 10 instances,
1024 (if (= batch-allocation-count 10)
1026 (set! batch-allocation-count 0)
1027 (set! batch-get-n-set #f)))
1028 ;; If we don't have a current pair of get and set closures,
1029 ;; create one. make-closure-variable returns a pair of closures
1030 ;; around a single Scheme variable - see goops.scm for details.
1032 (set! batch-get-n-set (make-closure-variable)))
1033 ;; Increment the batch allocation count.
1034 (set! batch-allocation-count (+ batch-allocation-count 1))
1037 ;; Call next-method to handle standard allocation types.
1038 (else (next-method)))))
1040 (define-class <class-using-batched-slot> ()
1042 (c #:allocation #:batched)
1044 #:metaclass <batched-allocation-metaclass>)
1047 The usage of @code{compute-getter-method} and @code{compute-setter-method}
1048 is described in @ref{MOP Specification}.
1050 @code{compute-cpl} and @code{compute-get-n-set} are called by the
1051 standard @code{initialize} method for classes whose metaclass is
1052 @code{<class>}. But @code{initialize} itself can also be modified, by
1053 defining an @code{initialize} method specialized to the new class's
1054 metaclass. Such a method could complete override the standard
1055 behaviour, by not calling @code{(next-method)} at all, but more
1056 typically it would perform additional class initialization steps before
1057 and/or after calling @code{(next-method)} for the standard behaviour.
1059 @node STKlos Compatibility
1060 @subsubsection STKlos Compatibility
1062 If the STKlos compatibility module is loaded, @code{define-class} is
1063 overwritten by a STKlos-specific definition; the standard GOOPS
1064 definition of @code{define-class} remains available in
1065 @code{standard-define-class}.
1067 @deffn syntax standard-define-class name (super @dots{}) slot-definition @dots{} . options
1068 @code{standard-define-class} is equivalent to the standard GOOPS
1069 @code{define-class}.
1072 @node Creating Instances
1073 @subsection Creating Instances
1076 * Basic Instance Creation::
1077 * Customizing Instance Creation::
1080 @node Basic Instance Creation
1081 @subsubsection Basic Instance Creation
1083 To create a new instance of any GOOPS class, use the generic function
1084 @code{make} or @code{make-instance}, passing the required class and any
1085 appropriate instance initialization arguments as keyword and value
1086 pairs. Note that @code{make} and @code{make-instances} are aliases for
1087 each other - their behaviour is identical.
1090 @deffnx method make (class <class>) . initargs
1091 Create and return a new instance of class @var{class}, initialized using
1094 In theory, @var{initargs} can have any structure that is understood by
1095 whatever methods get applied when the @code{initialize} generic function
1096 is applied to the newly allocated instance.
1098 In practice, specialized @code{initialize} methods would normally call
1099 @code{(next-method)}, and so eventually the standard GOOPS
1100 @code{initialize} methods are applied. These methods expect
1101 @var{initargs} to be a list with an even number of elements, where
1102 even-numbered elements (counting from zero) are keywords and
1103 odd-numbered elements are the corresponding values.
1105 GOOPS processes initialization argument keywords automatically for slots
1106 whose definition includes the @code{#:init-keyword} option (@pxref{Slot
1107 Options,, init-keyword}). Other keyword value pairs can only be
1108 processed by an @code{initialize} method that is specialized for the new
1109 instance's class. Any unprocessed keyword value pairs are ignored.
1112 @deffn generic make-instance
1113 @deffnx method make-instance (class <class>) . initargs
1114 @code{make-instance} is an alias for @code{make}.
1117 @node Customizing Instance Creation
1118 @subsubsection Customizing Instance Creation
1120 @code{make} itself is a generic function. Hence the @code{make}
1121 invocation itself can be customized in the case where the new instance's
1122 metaclass is more specialized than the default @code{<class>}, by
1123 defining a @code{make} method that is specialized to that metaclass.
1125 Normally, however, the method for classes with metaclass @code{<class>}
1126 will be applied. This method calls two generic functions:
1130 (allocate-instance @var{class} . @var{initargs})
1133 (initialize @var{instance} . @var{initargs})
1136 @code{allocate-instance} allocates storage for and returns the new
1137 instance, uninitialized. You might customize @code{allocate-instance},
1138 for example, if you wanted to provide a GOOPS wrapper around some other
1139 object programming system.
1141 To do this, you would create a specialized metaclass, which would act as
1142 the metaclass for all classes and instances from the other system. Then
1143 define an @code{allocate-instance} method, specialized to that
1144 metaclass, which calls a Guile primitive C function, which in turn
1145 allocates the new instance using the interface of the other object
1148 In this case, for a complete system, you would also need to customize a
1149 number of other generic functions like @code{make} and
1150 @code{initialize}, so that GOOPS knows how to make classes from the
1151 other system, access instance slots, and so on.
1153 @code{initialize} initializes the instance that is returned by
1154 @code{allocate-instance}. The standard GOOPS methods perform
1155 initializations appropriate to the instance class.
1159 At the least specialized level, the method for instances of type
1160 @code{<object>} performs internal GOOPS instance initialization, and
1161 initializes the instance's slots according to the slot definitions and
1162 any slot initialization keywords that appear in @var{initargs}.
1165 The method for instances of type @code{<class>} calls
1166 @code{(next-method)}, then performs the class initializations described
1167 in @ref{Customizing Class Definition}.
1170 and so on for generic functions, method, operator classes @dots{}
1173 Similarly, you can customize the initialization of instances of any
1174 application-defined class by defining an @code{initialize} method
1175 specialized to that class.
1177 Imagine a class whose instances' slots need to be initialized at
1178 instance creation time by querying a database. Although it might be
1179 possible to achieve this a combination of @code{#:init-thunk} keywords
1180 and closures in the slot definitions, it is neater to write an
1181 @code{initialize} method for the class that queries the database once
1182 and initializes all the dependent slot values according to the results.
1184 @node Accessing Slots
1185 @subsection Accessing Slots
1187 The definition of a slot contains at the very least a slot name, and may
1188 also contain various slot options, including getter, setter and/or
1189 accessor functions for the slot.
1191 It is always possible to access slots by name, using the various
1192 ``slot-ref'' and ``slot-set!'' procedures described in the following
1193 subsubsections. For example,
1196 (define-class <my-class> () ;; Define a class with slots
1197 (count #:init-value 0) ;; named "count" and "cache".
1198 (cache #:init-value '())
1201 (define inst (make <my-class>)) ;; Make an instance of this class.
1203 (slot-set! inst 'count 5) ;; Set the value of the "count"
1206 (slot-set! inst 'cache ;; Modify the value of the
1207 (cons (cons "^it" "It") ;; "cache" slot.
1208 (slot-ref inst 'cache)))
1211 If a slot definition includes a getter, setter or accessor function,
1212 these can be used instead of @code{slot-ref} and @code{slot-set!} to
1216 (define-class <adv-class> () ;; Define a new class whose slots
1217 (count #:setter set-count) ;; use a getter, a setter and
1218 (cache #:accessor cache) ;; an accessor.
1219 (csize #:getter cache-size)
1222 (define inst (make <adv-class>)) ;; Make an instance of this class.
1224 (set-count inst 5) ;; Set the value of the "count"
1227 (set! (cache inst) ;; Modify the value of the
1228 (cons (cons "^it" "It") ;; "cache" slot.
1231 (let ((size (cache-size inst))) ;; Get the value of the "csize"
1235 Whichever of these methods is used to access slots, GOOPS always calls
1236 the low-level @dfn{getter} and @dfn{setter} closures for the slot to get
1237 and set its value. These closures make sure that the slot behaves
1238 according to the @code{#:allocation} type that was specified in the slot
1239 definition (@pxref{Slot Options,, allocation}). (For more about these
1240 closures, see @ref{Customizing Class Definition,, compute-get-n-set}.)
1245 * Handling Slot Access Errors::
1248 @node Instance Slots
1249 @subsubsection Instance Slots
1251 Any slot, regardless of its allocation, can be queried, referenced and
1252 set using the following four primitive procedures.
1254 @deffn {primitive procedure} slot-exists? obj slot-name
1255 Return @code{#t} if @var{obj} has a slot with name @var{slot-name},
1256 otherwise @code{#f}.
1259 @deffn {primitive procedure} slot-bound? obj slot-name
1260 Return @code{#t} if the slot named @var{slot-name} in @var{obj} has a
1261 value, otherwise @code{#f}.
1263 @code{slot-bound?} calls the generic function @code{slot-missing} if
1264 @var{obj} does not have a slot called @var{slot-name} (@pxref{Handling
1265 Slot Access Errors, slot-missing}).
1268 @deffn {primitive procedure} slot-ref obj slot-name
1269 Return the value of the slot named @var{slot-name} in @var{obj}.
1271 @code{slot-ref} calls the generic function @code{slot-missing} if
1272 @var{obj} does not have a slot called @var{slot-name} (@pxref{Handling
1273 Slot Access Errors, slot-missing}).
1275 @code{slot-ref} calls the generic function @code{slot-unbound} if the
1276 named slot in @var{obj} does not have a value (@pxref{Handling Slot
1277 Access Errors, slot-unbound}).
1280 @deffn {primitive procedure} slot-set! obj slot-name value
1281 Set the value of the slot named @var{slot-name} in @var{obj} to @var{value}.
1283 @code{slot-set!} calls the generic function @code{slot-missing} if
1284 @var{obj} does not have a slot called @var{slot-name} (@pxref{Handling
1285 Slot Access Errors, slot-missing}).
1288 GOOPS stores information about slots in class metaobjects. Internally,
1289 all of these procedures work by looking up the slot definition for the
1290 slot named @var{slot-name} in the class metaobject for @code{(class-of
1291 @var{obj})}, and then using the slot definition's ``getter'' and
1292 ``setter'' closures to get and set the slot value.
1294 The next four procedures differ from the previous ones in that they take
1295 the class metaobject as an explicit argument, rather than assuming
1296 @code{(class-of @var{obj})}. Therefore they allow you to apply the
1297 ``getter'' and ``setter'' closures of a slot definition in one class to
1298 an instance of a different class.
1300 [ *fixme* I have no idea why this is useful! Perhaps when a slot in
1301 @code{(class-of @var{obj})} shadows a slot with the same name in one of
1302 its superclasses? There should be an enlightening example here. ]
1304 @deffn {primitive procedure} slot-exists-using-class? class obj slot-name
1305 Return @code{#t} if the class metaobject @var{class} has a slot
1306 definition for a slot with name @var{slot-name}, otherwise @code{#f}.
1309 @deffn {primitive procedure} slot-bound-using-class? class obj slot-name
1310 Return @code{#t} if applying @code{slot-ref-using-class} to the same
1311 arguments would call the generic function @code{slot-unbound}, otherwise
1314 @code{slot-bound-using-class?} calls the generic function
1315 @code{slot-missing} if @var{class} does not have a slot definition for a
1316 slot called @var{slot-name} (@pxref{Handling Slot Access Errors,
1320 @deffn {primitive procedure} slot-ref-using-class class obj slot-name
1321 Apply the ``getter'' closure for the slot named @var{slot-name} in
1322 @var{class} to @var{obj}, and return its result.
1324 @code{slot-ref-using-class} calls the generic function
1325 @code{slot-missing} if @var{class} does not have a slot definition for a
1326 slot called @var{slot-name} (@pxref{Handling Slot Access Errors,
1329 @code{slot-ref-using-class} calls the generic function
1330 @code{slot-unbound} if the application of the ``getter'' closure to
1331 @var{obj} returns an unbound value (@pxref{Handling Slot Access Errors,
1335 @deffn {primitive procedure} slot-set-using-class! class obj slot-name value
1336 Apply the ``setter'' closure for the slot named @var{slot-name} in
1337 @var{class} to @var{obj} and @var{value}.
1339 @code{slot-set-using-class!} calls the generic function
1340 @code{slot-missing} if @var{class} does not have a slot definition for a
1341 slot called @var{slot-name} (@pxref{Handling Slot Access Errors,
1346 @subsubsection Class Slots
1348 Slots whose allocation is per-class rather than per-instance can be
1349 referenced and set without needing to specify any particular instance.
1351 @deffn procedure class-slot-ref class slot-name
1352 Return the value of the slot named @var{slot-name} in class @var{class}.
1353 The named slot must have @code{#:class} or @code{#:each-subclass}
1354 allocation (@pxref{Slot Options,, allocation}).
1356 If there is no such slot with @code{#:class} or @code{#:each-subclass}
1357 allocation, @code{class-slot-ref} calls the @code{slot-missing} generic
1358 function with arguments @var{class} and @var{slot-name}. Otherwise, if
1359 the slot value is unbound, @code{class-slot-ref} calls the
1360 @code{slot-missing} generic function, with the same arguments.
1363 @deffn procedure class-slot-set! class slot-name value
1364 Set the value of the slot named @var{slot-name} in class @var{class} to
1365 @var{value}. The named slot must have @code{#:class} or
1366 @code{#:each-subclass} allocation (@pxref{Slot Options,, allocation}).
1368 If there is no such slot with @code{#:class} or @code{#:each-subclass}
1369 allocation, @code{class-slot-ref} calls the @code{slot-missing} generic
1370 function with arguments @var{class} and @var{slot-name}.
1373 @node Handling Slot Access Errors
1374 @subsubsection Handling Slot Access Errors
1376 GOOPS calls one of the following generic functions when a ``slot-ref''
1377 or ``slot-set!'' call specifies a non-existent slot name, or tries to
1378 reference a slot whose value is unbound.
1380 @deffn generic slot-missing
1381 @deffnx method slot-missing (class <class>) slot-name
1382 @deffnx method slot-missing (class <class>) (object <object>) slot-name
1383 @deffnx method slot-missing (class <class>) (object <object>) slot-name value
1384 When an application attempts to reference or set a class or instance
1385 slot by name, and the slot name is invalid for the specified @var{class}
1386 or @var{object}, GOOPS calls the @code{slot-missing} generic function.
1388 The default methods all call @code{goops-error} with an appropriate
1392 @deffn generic slot-unbound
1393 @deffnx method slot-unbound (object <object>)
1394 @deffnx method slot-unbound (class <class>) slot-name
1395 @deffnx method slot-unbound (class <class>) (object <object>) slot-name
1396 When an application attempts to reference a class or instance slot, and
1397 the slot's value is unbound, GOOPS calls the @code{slot-unbound} generic
1400 The default methods all call @code{goops-error} with an appropriate
1404 @node Creating Generic Functions
1405 @subsection Creating Generic Functions
1407 A generic function is a collection of methods, with rules for
1408 determining which of the methods should be applied for any given
1409 invocation of the generic function.
1411 GOOPS represents generic functions as metaobjects of the class
1412 @code{<generic>} (or one of its subclasses).
1415 * Basic Generic Function Creation::
1416 * Generic Function Internals::
1417 * Extending Guiles Primitives::
1420 @node Basic Generic Function Creation
1421 @subsubsection Basic Generic Function Creation
1423 The following forms may be used to bind a variable to a generic
1424 function. Depending on that variable's pre-existing value, the generic
1425 function may be created empty - with no methods - or it may contain
1426 methods that are inferred from the pre-existing value.
1428 It is not, in general, necessary to use @code{define-generic} or
1429 @code{define-accessor} before defining methods for the generic function
1430 using @code{define-method}, since @code{define-method} will
1431 automatically interpolate a @code{define-generic} call, or upgrade an
1432 existing generic to an accessor, if that is implied by the
1433 @code{define-method} call. Note in particular that,
1434 if the specified variable already has a @emph{generic function} value,
1435 @code{define-generic} and @code{define-accessor} will @emph{discard} it!
1436 Obviously it is application-dependent whether this is desirable or not.
1438 If, for example, you wanted to extend @code{+} for a class representing
1439 a new numerical type, you probably want to inherit any existing methods
1440 for @code{+} and so should not use @code{define-generic}. If, on the
1441 other hand, you do not want to risk inheriting methods whose behaviour
1442 might surprise you, you can use @code{define-generic} or
1443 @code{define-accessor} to wipe the slate clean.
1445 @deffn syntax define-generic symbol
1446 Create a generic function with name @var{symbol} and bind it to the
1447 variable @var{symbol}.
1449 If the variable @var{symbol} was previously bound to a Scheme procedure
1450 (or procedure-with-setter), the old procedure (and setter) is
1451 incorporated into the new generic function as its default procedure (and
1452 setter). Any other previous value that was bound to @var{symbol},
1453 including an existing generic function, is overwritten by the new
1457 @deffn syntax define-accessor symbol
1458 Create an accessor with name @var{symbol} and bind it to the variable
1461 If the variable @var{symbol} was previously bound to a Scheme procedure
1462 (or procedure-with-setter), the old procedure (and setter) is
1463 incorporated into the new accessor as its default procedure (and
1464 setter). Any other previous value that was bound to @var{symbol},
1465 including an existing generic function or accessor, is overwritten by
1469 It is sometimes tempting to use GOOPS accessors with short names. For
1470 example, it is tempting to use the name @code{x} for the x-coordinate
1473 Assume that we work with a graphical package which needs to use two
1474 independent vector packages for 2D and 3D vectors respectively. If
1475 both packages export @code{x} we will encounter a name collision.
1477 This can be resolved automagically with the duplicates handler
1478 @code{merge-generics} which gives the module system license to merge
1479 all generic functions sharing a common name:
1482 (define-module (math 2D-vectors)
1483 :use-module (oop goops)
1486 (define-module (math 3D-vectors)
1487 :use-module (oop goops)
1488 :export (x y z ...))
1490 (define-module (my-module)
1491 :use-module (math 2D-vectors)
1492 :use-module (math 3D-vectors)
1493 :duplicates merge-generics)
1496 The generic function @code{x} in @code{(my-module)} will now share
1497 methods with @code{x} in both imported modules.
1499 There will, in fact, now be three distinct generic functions named
1500 @code{x}: @code{x} in @code{(2D-vectors)}, @code{x} in
1501 @code{(3D-vectors)}, and @code{x} in @code{(my-module)}. The last
1502 function will be an @code{<extended-generic>}, extending the previous
1505 Let's call the imported generic functions the "ancestor functions".
1506 The generic function @code{x} in @code{(my-module)} is, in turn, a
1507 "descendant function" of the imported functions, extending its
1510 For any generic function G, the applicable methods are selected from
1511 the union of the methods of the descendant functions, the methods of G
1512 itself and the methods of the ancestor functions.
1514 This, ancestor functions share methods with their descendants and vice
1515 versa. This implies that @code{x} in @code{(math 2D-vectors)} will
1516 share the methods of @code{x} in @code{(my-module)} and vice versa,
1517 while @code{x} in @code{(math 2D-vectors)} doesn't share the methods
1518 of @code{x} in @code{(math 3D-vectors)}, thus preserving modularity.
1520 Sharing is dynamic, so that adding new methods to a descendant implies
1521 adding it to the ancestor.
1523 If duplicates checking is desired in the above example, the following
1524 form of the @code{:duplicates} option can be used instead:
1527 :duplicates (merge-generics check)
1530 @node Generic Function Internals
1531 @subsubsection Generic Function Internals
1533 @code{define-generic} calls @code{ensure-generic} to upgrade a
1534 pre-existing procedure value, or @code{make} with metaclass
1535 @code{<generic>} to create a new generic function.
1537 @code{define-accessor} calls @code{ensure-accessor} to upgrade a
1538 pre-existing procedure value, or @code{make-accessor} to create a new
1541 @deffn procedure ensure-generic old-definition [name]
1542 Return a generic function with name @var{name}, if possible by using or
1543 upgrading @var{old-definition}. If unspecified, @var{name} defaults to
1546 If @var{old-definition} is already a generic function, it is returned
1549 If @var{old-definition} is a Scheme procedure or procedure-with-setter,
1550 @code{ensure-generic} returns a new generic function that uses
1551 @var{old-definition} for its default procedure and setter.
1553 Otherwise @code{ensure-generic} returns a new generic function with no
1554 defaults and no methods.
1557 @deffn procedure make-generic [name]
1558 Return a new generic function with name @code{(car @var{name})}. If
1559 unspecified, @var{name} defaults to @code{#f}.
1562 @code{ensure-generic} calls @code{make} with metaclasses
1563 @code{<generic>} and @code{<generic-with-setter>}, depending on the
1564 previous value of the variable that it is trying to upgrade.
1566 @code{make-generic} is a simple wrapper for @code{make} with metaclass
1569 @deffn procedure ensure-accessor proc [name]
1570 Return an accessor with name @var{name}, if possible by using or
1571 upgrading @var{proc}. If unspecified, @var{name} defaults to @code{#f}.
1573 If @var{proc} is already an accessor, it is returned unchanged.
1575 If @var{proc} is a Scheme procedure, procedure-with-setter or generic
1576 function, @code{ensure-accessor} returns an accessor that reuses the
1577 reusable elements of @var{proc}.
1579 Otherwise @code{ensure-accessor} returns a new accessor with no defaults
1583 @deffn procedure make-accessor [name]
1584 Return a new accessor with name @code{(car @var{name})}. If
1585 unspecified, @var{name} defaults to @code{#f}.
1588 @code{ensure-accessor} calls @code{make} with
1589 metaclass @code{<generic-with-setter>}, as well as calls to
1590 @code{ensure-generic}, @code{make-accessor} and (tail recursively)
1591 @code{ensure-accessor}.
1593 @code{make-accessor} calls @code{make} twice, first
1594 with metaclass @code{<generic>} to create a generic function for the
1595 setter, then with metaclass @code{<generic-with-setter>} to create the
1596 accessor, passing the setter generic function as the value of the
1597 @code{#:setter} keyword.
1599 @node Extending Guiles Primitives
1600 @subsubsection Extending Guile's Primitives
1602 When GOOPS is loaded, many of Guile's primitive procedures can be
1603 extended by giving them a generic function definition that operates
1604 in conjunction with their normal C-coded implementation. For
1605 primitives that are extended in this way, the result from the user-
1606 or application-level point of view is that the extended primitive
1607 behaves exactly like a generic function with the C-coded implementation
1608 as its default method.
1610 The @code{generic-capability?} predicate should be used to determine
1611 whether a particular primitive is extensible in this way.
1613 @deffn {primitive procedure} generic-capability? primitive
1614 Return @code{#t} if @var{primitive} can be extended by giving it a
1615 generic function definition, otherwise @code{#f}.
1618 Even when a primitive procedure is extensible like this, its generic
1619 function definition is not created until it is needed by a call to
1620 @code{define-method}, or until the application explicitly requests it
1621 by calling @code{enable-primitive-generic!}.
1623 @deffn {primitive procedure} enable-primitive-generic! primitive
1624 Force the creation of a generic function definition for
1628 Once the generic function definition for a primitive has been created,
1629 it can be retrieved using @code{primitive-generic-generic}.
1631 @deffn {primitive procedure} primitive-generic-generic primitive
1632 Return the generic function definition of @var{primitive}.
1634 @code{primitive-generic-generic} raises an error if @var{primitive}
1635 is not a primitive with generic capability, or if its generic capability
1636 has not yet been enabled, whether implicitly (by @code{define-method})
1637 or explicitly (by @code{enable-primitive-generic!}).
1640 Note that the distinction between, on the one hand, primitives with
1641 additional generic function definitions and, on the other hand, generic
1642 functions with a default method, may disappear when GOOPS is fully
1643 integrated into the core of Guile. Consequently, the
1644 procedures described in this section may disappear as well.
1646 @node Adding Methods to Generic Functions
1647 @subsection Adding Methods to Generic Functions
1650 * Basic Method Definition::
1651 * Method Definition Internals::
1654 @node Basic Method Definition
1655 @subsubsection Basic Method Definition
1657 To add a method to a generic function, use the @code{define-method} form.
1659 @deffn syntax define-method (generic parameter @dots{}) . body
1660 Define a method for the generic function or accessor @var{generic} with
1661 parameters @var{parameter}s and body @var{body}.
1663 @var{generic} is a generic function. If @var{generic} is a variable
1664 which is not yet bound to a generic function object, the expansion of
1665 @code{define-method} will include a call to @code{define-generic}. If
1666 @var{generic} is @code{(setter @var{generic-with-setter})}, where
1667 @var{generic-with-setter} is a variable which is not yet bound to a
1668 generic-with-setter object, the expansion will include a call to
1669 @code{define-accessor}.
1671 Each @var{parameter} must be either a symbol or a two-element list
1672 @code{(@var{symbol} @var{class})}. The symbols refer to variables in
1673 the @var{body} that will be bound to the parameters supplied by the
1674 caller when calling this method. The @var{class}es, if present,
1675 specify the possible combinations of parameters to which this method
1678 @var{body} is the body of the method definition.
1681 @code{define-method} expressions look a little like normal Scheme
1682 procedure definitions of the form
1685 (define (name formals @dots{}) . body)
1688 The most important difference is that each formal parameter, apart from the
1689 possible ``rest'' argument, can be qualified by a class name:
1690 @code{@var{formal}} becomes @code{(@var{formal} @var{class})}. The
1691 meaning of this qualification is that the method being defined
1692 will only be applicable in a particular generic function invocation if
1693 the corresponding argument is an instance of @code{@var{class}} (or one of
1694 its subclasses). If more than one of the formal parameters is qualified
1695 in this way, then the method will only be applicable if each of the
1696 corresponding arguments is an instance of its respective qualifying class.
1698 Note that unqualified formal parameters act as though they are qualified
1699 by the class @code{<top>}, which GOOPS uses to mean the superclass of
1700 all valid Scheme types, including both primitive types and GOOPS classes.
1702 For example, if a generic function method is defined with
1703 @var{parameter}s @code{((s1 <square>) (n <number>))}, that method is
1704 only applicable to invocations of its generic function that have two
1705 parameters where the first parameter is an instance of the
1706 @code{<square>} class and the second parameter is a number.
1708 If a generic function is invoked with a combination of parameters for which
1709 there is no applicable method, GOOPS raises an error. For more about
1710 invocation error handling, and generic function invocation in general,
1711 see @ref{Invoking Generic Functions}.
1713 @node Method Definition Internals
1714 @subsubsection Method Definition Internals
1716 @code{define-method}
1720 checks the form of the first parameter, and applies the following steps
1721 to the accessor's setter if it has the @code{(setter @dots{})} form
1724 interpolates a call to @code{define-generic} or @code{define-accessor}
1725 if a generic function is not already defined with the supplied name
1728 calls @code{method} with the @var{parameter}s and @var{body}, to make a
1732 calls @code{add-method!} to add this method to the relevant generic
1736 @deffn syntax method (parameter @dots{}) . body
1737 Make a method whose specializers are defined by the classes in
1738 @var{parameter}s and whose procedure definition is constructed from the
1739 @var{parameter} symbols and @var{body} forms.
1741 The @var{parameter} and @var{body} parameters should be as for
1742 @code{define-method} (@pxref{Basic Method Definition,, define-method}).
1749 extracts formals and specializing classes from the @var{parameter}s,
1750 defaulting the class for unspecialized parameters to @code{<top>}
1753 creates a closure using the formals and the @var{body} forms
1756 calls @code{make} with metaclass @code{<method>} and the specializers
1757 and closure using the @code{#:specializers} and @code{#:procedure}
1761 @deffn procedure make-method specializers procedure
1762 Make a method using @var{specializers} and @var{procedure}.
1764 @var{specializers} should be a list of classes that specifies the
1765 parameter combinations to which this method will be applicable.
1767 @var{procedure} should be the closure that will applied to the generic
1768 function parameters when this method is invoked.
1771 @code{make-method} is a simple wrapper around @code{make} with metaclass
1774 @deffn generic add-method! target method
1775 Generic function for adding method @var{method} to @var{target}.
1778 @deffn method add-method! (generic <generic>) (method <method>)
1779 Add method @var{method} to the generic function @var{generic}.
1782 @deffn method add-method! (proc <procedure>) (method <method>)
1783 If @var{proc} is a procedure with generic capability (@pxref{Extending
1784 Guiles Primitives,, generic-capability?}), upgrade it to a
1785 primitive generic and add @var{method} to its generic function
1789 @deffn method add-method! (pg <primitive-generic>) (method <method>)
1790 Add method @var{method} to the generic function definition of @var{pg}.
1792 Implementation: @code{(add-method! (primitive-generic-generic pg) method)}.
1795 @deffn method add-method! (whatever <top>) (method <method>)
1796 Raise an error indicating that @var{whatever} is not a valid generic
1800 @node Invoking Generic Functions
1801 @subsection Invoking Generic Functions
1803 When a variable with a generic function definition appears as the first
1804 element of a list that is being evaluated, the Guile evaluator tries
1805 to apply the generic function to the arguments obtained by evaluating
1806 the remaining elements of the list. [ *fixme* How do I put this in a
1807 more Schemely and less Lispy way? ]
1809 Usually a generic function contains several method definitions, with
1810 varying degrees of formal parameter specialization (@pxref{Basic
1811 Method Definition,, define-method}). So it is necessary to sort these
1812 methods by specificity with respect to the supplied arguments, and then
1813 apply the most specific method definition. Less specific methods
1814 may be applied subsequently if a method that is being applied calls
1818 * Determining Which Methods to Apply::
1819 * Handling Invocation Errors::
1822 @node Determining Which Methods to Apply
1823 @subsubsection Determining Which Methods to Apply
1825 [ *fixme* Sorry - this is the area of GOOPS that I understand least of
1826 all, so I'm afraid I have to pass on this section. Would some other
1827 kind person consider filling it in? ]
1829 @deffn generic apply-generic
1830 @deffnx method apply-generic (gf <generic>) args
1833 @deffn generic compute-applicable-methods
1834 @deffnx method compute-applicable-methods (gf <generic>) args
1837 @deffn generic sort-applicable-methods
1838 @deffnx method sort-applicable-methods (gf <generic>) methods args
1841 @deffn generic method-more-specific?
1842 @deffnx method method-more-specific? (m1 <method>) (m2 <method>) args
1845 @deffn generic apply-method
1846 @deffnx method apply-method (gf <generic>) methods build-next args
1849 @deffn generic apply-methods
1850 @deffnx method apply-methods (gf <generic>) (l <list>) args
1853 @node Handling Invocation Errors
1854 @subsubsection Handling Invocation Errors
1856 @deffn generic no-method
1857 @deffnx method no-method (gf <generic>) args
1858 When an application invokes a generic function, and no methods at all
1859 have been defined for that generic function, GOOPS calls the
1860 @code{no-method} generic function. The default method calls
1861 @code{goops-error} with an appropriate message.
1864 @deffn generic no-applicable-method
1865 @deffnx method no-applicable-method (gf <generic>) args
1866 When an application applies a generic function to a set of arguments,
1867 and no methods have been defined for those argument types, GOOPS calls
1868 the @code{no-applicable-method} generic function. The default method
1869 calls @code{goops-error} with an appropriate message.
1872 @deffn generic no-next-method
1873 @deffnx method no-next-method (gf <generic>) args
1874 When a generic function method calls @code{(next-method)} to invoke the
1875 next less specialized method for that generic function, and no less
1876 specialized methods have been defined for the current generic function
1877 arguments, GOOPS calls the @code{no-next-method} generic function. The
1878 default method calls @code{goops-error} with an appropriate message.
1881 @node Redefining a Class
1882 @subsection Redefining a Class
1884 Suppose that a class @code{<my-class>} is defined using @code{define-class}
1885 (@pxref{Basic Class Definition,, define-class}), with slots that have
1886 accessor functions, and that an application has created several instances
1887 of @code{<my-class>} using @code{make} (@pxref{Basic Instance Creation,,
1888 make}). What then happens if @code{<my-class>} is redefined by calling
1889 @code{define-class} again?
1892 * Default Class Redefinition Behaviour::
1893 * Customizing Class Redefinition::
1896 @node Default Class Redefinition Behaviour
1897 @subsubsection Default Class Redefinition Behaviour
1899 GOOPS' default answer to this question is as follows.
1903 All existing direct instances of @code{<my-class>} are converted to be
1904 instances of the new class. This is achieved by preserving the values
1905 of slots that exist in both the old and new definitions, and initializing the
1906 values of new slots in the usual way (@pxref{Basic Instance Creation,,
1910 All existing subclasses of @code{<my-class>} are redefined, as though
1911 the @code{define-class} expressions that defined them were re-evaluated
1912 following the redefinition of @code{<my-class>}, and the class
1913 redefinition process described here is applied recursively to the
1914 redefined subclasses.
1917 Once all of its instances and subclasses have been updated, the class
1918 metaobject previously bound to the variable @code{<my-class>} is no
1919 longer needed and so can be allowed to be garbage collected.
1922 To keep things tidy, GOOPS also needs to do a little housekeeping on
1923 methods that are associated with the redefined class.
1927 Slot accessor methods for slots in the old definition should be removed
1928 from their generic functions. They will be replaced by accessor methods
1929 for the slots of the new class definition.
1932 Any generic function method that uses the old @code{<my-class>} metaobject
1933 as one of its formal parameter specializers must be updated to refer to
1934 the new @code{<my-class>} metaobject. (Whenever a new generic function
1935 method is defined, @code{define-method} adds the method to a list stored
1936 in the class metaobject for each class used as a formal parameter
1937 specializer, so it is easy to identify all the methods that must be
1938 updated when a class is redefined.)
1941 If this class redefinition strategy strikes you as rather counter-intuitive,
1942 bear in mind that it is derived from similar behaviour in other object
1943 systems such as CLOS, and that experience in those systems has shown it to be
1944 very useful in practice.
1946 Also bear in mind that, like most of GOOPS' default behaviour, it can
1947 be customized@dots{}
1949 @node Customizing Class Redefinition
1950 @subsubsection Customizing Class Redefinition
1952 When @code{define-class} notices that a class is being redefined,
1953 it constructs the new class metaobject as usual, and then invokes the
1954 @code{class-redefinition} generic function with the old and new classes
1955 as arguments. Therefore, if the old or new classes have metaclasses
1956 other than the default @code{<class>}, class redefinition behaviour can
1957 be customized by defining a @code{class-redefinition} method that is
1958 specialized for the relevant metaclasses.
1960 @deffn generic class-redefinition
1961 Handle the class redefinition from @var{old-class} to @var{new-class},
1962 and return the new class metaobject that should be bound to the
1963 variable specified by @code{define-class}'s first argument.
1966 @deffn method class-redefinition (old-class <class>) (new-class <class>)
1967 Implements GOOPS' default class redefinition behaviour, as described in
1968 @ref{Default Class Redefinition Behaviour}. Returns the metaobject
1969 for the new class definition.
1972 An alternative class redefinition strategy could be to leave all
1973 existing instances as instances of the old class, but accepting that the
1974 old class is now ``nameless'', since its name has been taken over by the
1975 new definition. In this strategy, any existing subclasses could also
1976 be left as they are, on the understanding that they inherit from a nameless
1979 This strategy is easily implemented in GOOPS, by defining a new metaclass,
1980 that will be used as the metaclass for all classes to which the strategy
1981 should apply, and then defining a @code{class-redefinition} method that
1982 is specialized for this metaclass:
1985 (define-class <can-be-nameless> (<class>))
1987 (define-method (class-redefinition (old <can-be-nameless>)
1992 When customization can be as easy as this, aren't you glad that GOOPS
1993 implements the far more difficult strategy as its default!
1995 Finally, note that, if @code{class-redefinition} itself is not customized,
1996 the default @code{class-redefinition} method invokes three further
1997 generic functions that could be individually customized:
2001 (remove-class-accessors! @var{old-class})
2004 (update-direct-method! @var{method} @var{old-class} @var{new-class})
2007 (update-direct-subclass! @var{subclass} @var{old-class} @var{new-class})
2010 and the default methods for these generic functions invoke further
2011 generic functions, and so on@dots{} The detailed protocol for all of these
2012 is described in @ref{MOP Specification}.
2014 @node Changing the Class of an Instance
2015 @subsection Changing the Class of an Instance
2017 You can change the class of an existing instance by invoking the
2018 generic function @code{change-class} with two arguments: the instance
2021 @deffn generic change-class
2024 The default method for @code{change-class} decides how to implement the
2025 change of class by looking at the slot definitions for the instance's
2026 existing class and for the new class. If the new class has slots with
2027 the same name as slots in the existing class, the values for those slots
2028 are preserved. Slots that are present only in the existing class are
2029 discarded. Slots that are present only in the new class are initialized
2030 using the corresponding slot definition's init function (@pxref{Classes,,
2031 slot-init-function}).
2033 @deffn {method} change-class (obj <object>) (new <class>)
2034 Modify instance @var{obj} to make it an instance of class @var{new}.
2036 The value of each of @var{obj}'s slots is preserved only if a similarly named
2037 slot exists in @var{new}; any other slot values are discarded.
2039 The slots in @var{new} that do not correspond to any of @var{obj}'s
2040 pre-existing slots are initialized according to @var{new}'s slot definitions'
2044 Customized change of class behaviour can be implemented by defining
2045 @code{change-class} methods that are specialized either by the class
2046 of the instances to be modified or by the metaclass of the new class.
2048 When a class is redefined (@pxref{Redefining a Class}), and the default
2049 class redefinition behaviour is not overridden, GOOPS (eventually)
2050 invokes the @code{change-class} generic function for each existing
2051 instance of the redefined class.
2054 @subsection Introspection
2056 @dfn{Introspection}, also known as @dfn{reflection}, is the name given
2057 to the ability to obtain information dynamically about GOOPS metaobjects.
2058 It is perhaps best illustrated by considering an object oriented language
2059 that does not provide any introspection, namely C++.
2061 Nothing in C++ allows a running program to obtain answers to the following
2066 What are the data members of this object or class?
2069 What classes does this class inherit from?
2072 Is this method call virtual or non-virtual?
2075 If I invoke @code{Employee::adjustHoliday()}, what class contains the
2076 @code{adjustHoliday()} method that will be applied?
2079 In C++, answers to such questions can only be determined by looking at
2080 the source code, if you have access to it. GOOPS, on the other hand,
2081 includes procedures that allow answers to these questions --- or their
2082 GOOPS equivalents --- to be obtained dynamically, at run time.
2088 * Generic Functions::
2089 * Generic Function Methods::
2093 @subsubsection Classes
2095 @deffn {primitive procedure} class-name class
2096 Return the name of class @var{class}.
2097 This is the value of the @var{class} metaobject's @code{name} slot.
2100 @deffn {primitive procedure} class-direct-supers class
2101 Return a list containing the direct superclasses of @var{class}.
2102 This is the value of the @var{class} metaobject's
2103 @code{direct-supers} slot.
2106 @deffn {primitive procedure} class-direct-slots class
2107 Return a list containing the slot definitions of the direct slots of
2109 This is the value of the @var{class} metaobject's @code{direct-slots}
2113 @deffn {primitive procedure} class-direct-subclasses class
2114 Return a list containing the direct subclasses of @var{class}.
2115 This is the value of the @var{class} metaobject's
2116 @code{direct-subclasses} slot.
2119 @deffn {primitive procedure} class-direct-methods class
2120 Return a list of all the generic function methods that use @var{class}
2121 as a formal parameter specializer.
2122 This is the value of the @var{class} metaobject's @code{direct-methods}
2126 @deffn {primitive procedure} class-precedence-list class
2127 Return the class precedence list for class @var{class} (@pxref{Class
2129 This is the value of the @var{class} metaobject's @code{cpl} slot.
2132 @deffn {primitive procedure} class-slots class
2133 Return a list containing the slot definitions for all @var{class}'s slots,
2134 including any slots that are inherited from superclasses.
2135 This is the value of the @var{class} metaobject's @code{slots} slot.
2138 @deffn {primitive procedure} class-environment class
2139 Return the value of @var{class}'s @code{environment} slot.
2140 [ *fixme* I don't know what this value is used for. ]
2143 @deffn procedure class-subclasses class
2144 Return a list of all subclasses of @var{class}.
2147 @deffn procedure class-methods class
2148 Return a list of all methods that use @var{class} or a subclass of
2149 @var{class} as one of its formal parameter specializers.
2153 @subsubsection Slots
2155 @deffn procedure class-slot-definition class slot-name
2156 Return the slot definition for the slot named @var{slot-name} in class
2157 @var{class}. @var{slot-name} should be a symbol.
2160 @deffn procedure slot-definition-name slot-def
2161 Extract and return the slot name from @var{slot-def}.
2164 @deffn procedure slot-definition-options slot-def
2165 Extract and return the slot options from @var{slot-def}.
2168 @deffn procedure slot-definition-allocation slot-def
2169 Extract and return the slot allocation option from @var{slot-def}. This
2170 is the value of the @code{#:allocation} keyword (@pxref{Slot Options,,
2171 allocation}), or @code{#:instance} if the @code{#:allocation} keyword is
2175 @deffn procedure slot-definition-getter slot-def
2176 Extract and return the slot getter option from @var{slot-def}. This is
2177 the value of the @code{#:getter} keyword (@pxref{Slot Options,,
2178 getter}), or @code{#f} if the @code{#:getter} keyword is absent.
2181 @deffn procedure slot-definition-setter slot-def
2182 Extract and return the slot setter option from @var{slot-def}. This is
2183 the value of the @code{#:setter} keyword (@pxref{Slot Options,,
2184 setter}), or @code{#f} if the @code{#:setter} keyword is absent.
2187 @deffn procedure slot-definition-accessor slot-def
2188 Extract and return the slot accessor option from @var{slot-def}. This
2189 is the value of the @code{#:accessor} keyword (@pxref{Slot Options,,
2190 accessor}), or @code{#f} if the @code{#:accessor} keyword is absent.
2193 @deffn procedure slot-definition-init-value slot-def
2194 Extract and return the slot init-value option from @var{slot-def}. This
2195 is the value of the @code{#:init-value} keyword (@pxref{Slot Options,,
2196 init-value}), or the unbound value if the @code{#:init-value} keyword is
2200 @deffn procedure slot-definition-init-form slot-def
2201 Extract and return the slot init-form option from @var{slot-def}. This
2202 is the value of the @code{#:init-form} keyword (@pxref{Slot Options,,
2203 init-form}), or the unbound value if the @code{#:init-form} keyword is
2207 @deffn procedure slot-definition-init-thunk slot-def
2208 Extract and return the slot init-thunk option from @var{slot-def}. This
2209 is the value of the @code{#:init-thunk} keyword (@pxref{Slot Options,,
2210 init-thunk}), or @code{#f} if the @code{#:init-thunk} keyword is absent.
2213 @deffn procedure slot-definition-init-keyword slot-def
2214 Extract and return the slot init-keyword option from @var{slot-def}.
2215 This is the value of the @code{#:init-keyword} keyword (@pxref{Slot
2216 Options,, init-keyword}), or @code{#f} if the @code{#:init-keyword}
2220 @deffn procedure slot-init-function class slot-name
2221 Return the initialization function for the slot named @var{slot-name} in
2222 class @var{class}. @var{slot-name} should be a symbol.
2224 The returned initialization function incorporates the effects of the
2225 standard @code{#:init-thunk}, @code{#:init-form} and @code{#:init-value}
2226 slot options. These initializations can be overridden by the
2227 @code{#:init-keyword} slot option or by a specialized @code{initialize}
2228 method, so, in general, the function returned by
2229 @code{slot-init-function} may be irrelevant. For a fuller discussion,
2230 see @ref{Slot Options,, init-value}.
2234 @subsubsection Instances
2236 @deffn {primitive procedure} class-of value
2237 Return the GOOPS class of any Scheme @var{value}.
2240 @deffn {primitive procedure} instance? object
2241 Return @code{#t} if @var{object} is any GOOPS instance, otherwise
2245 @deffn procedure is-a? object class
2246 Return @code{#t} if @var{object} is an instance of @var{class} or one of
2250 Implementation notes: @code{is-a?} uses @code{class-of} and
2251 @code{class-precedence-list} to obtain the class precedence list for
2254 @node Generic Functions
2255 @subsubsection Generic Functions
2257 @deffn {primitive procedure} generic-function-name gf
2258 Return the name of generic function @var{gf}.
2261 @deffn {primitive procedure} generic-function-methods gf
2262 Return a list of the methods of generic function @var{gf}.
2263 This is the value of the @var{gf} metaobject's @code{methods} slot.
2266 @node Generic Function Methods
2267 @subsubsection Generic Function Methods
2269 @deffn {primitive procedure} method-generic-function method
2270 Return the generic function that @var{method} belongs to.
2271 This is the value of the @var{method} metaobject's
2272 @code{generic-function} slot.
2275 @deffn {primitive procedure} method-specializers method
2276 Return a list of @var{method}'s formal parameter specializers .
2277 This is the value of the @var{method} metaobject's
2278 @code{specializers} slot.
2281 @deffn {primitive procedure} method-procedure method
2282 Return the procedure that implements @var{method}.
2283 This is the value of the @var{method} metaobject's
2284 @code{procedure} slot.
2287 @deffn generic method-source
2288 @deffnx method method-source (m <method>)
2289 Return an expression that prints to show the definition of method
2293 (define-generic cube)
2295 (define-method (cube (n <number>))
2298 (map method-source (generic-function-methods cube))
2300 ((method ((n <number>)) (* n n n)))
2304 @node Miscellaneous Functions
2305 @subsection Miscellaneous Functions
2308 * Administrative Functions::
2309 * GOOPS Error Handling::
2310 * Object Comparisons::
2312 * Write and Display::
2315 @node Administrative Functions
2316 @subsubsection Administration Functions
2318 This section describes administrative, non-technical GOOPS functions.
2320 @deffn primitive goops-version
2321 Return the current GOOPS version as a string, for example ``0.2''.
2324 @node GOOPS Error Handling
2325 @subsubsection Error Handling
2327 The procedure @code{goops-error} is called to raise an appropriate error
2328 by the default methods of the following generic functions:
2332 @code{slot-missing} (@pxref{Handling Slot Access Errors,, slot-missing})
2335 @code{slot-unbound} (@pxref{Handling Slot Access Errors,, slot-unbound})
2338 @code{no-method} (@pxref{Handling Invocation Errors,, no-method})
2341 @code{no-applicable-method} (@pxref{Handling Invocation Errors,,
2342 no-applicable-method})
2345 @code{no-next-method} (@pxref{Handling Invocation Errors,,
2349 If you customize these functions for particular classes or metaclasses,
2350 you may still want to use @code{goops-error} to signal any error
2351 conditions that you detect.
2353 @deffn procedure goops-error format-string . args
2354 Raise an error with key @code{goops-error} and error message constructed
2355 from @var{format-string} and @var{args}. Error message formatting is
2356 as done by @code{scm-error}.
2359 @node Object Comparisons
2360 @subsubsection Object Comparisons
2363 @deffnx method eqv? ((x <top>) (y <top>))
2364 @deffnx generic equal?
2365 @deffnx method equal? ((x <top>) (y <top>))
2367 @deffnx method = ((x <number>) (y <number>))
2368 Generic functions and default (unspecialized) methods for comparing two
2371 The default method for @code{eqv?} returns @code{#t} for all values
2372 that are equal in the sense defined by R5RS and the Guile reference
2373 manual, otherwise @code{#f}. The default method for @code{equal?}
2374 returns @code{#t} or @code{#f} in the sense defined by R5RS and the
2375 Guile reference manual. If no such comparison is defined,
2376 @code{equal?} returns the result of a call to @code{eqv?}. The
2377 default method for = returns @code{#t} if @var{x} and @var{y} are
2378 numerically equal, otherwise @code{#f}.
2380 Application class authors may wish to define specialized methods for
2381 @code{eqv?}, @code{equal?} and @code{=} that compare instances of the
2382 same class for equality in whatever sense is useful to the
2383 application. Such methods will only be called if the arguments have
2384 the same class and the result of the comparison isn't defined by R5RS
2385 and the Guile reference manual.
2388 @node Cloning Objects
2389 @subsubsection Cloning Objects
2391 @deffn generic shallow-clone
2392 @deffnx method shallow-clone (self <object>)
2393 Return a ``shallow'' clone of @var{self}. The default method makes a
2394 shallow clone by allocating a new instance and copying slot values from
2395 self to the new instance. Each slot value is copied either as an
2396 immediate value or by reference.
2399 @deffn generic deep-clone
2400 @deffnx method deep-clone (self <object>)
2401 Return a ``deep'' clone of @var{self}. The default method makes a deep
2402 clone by allocating a new instance and copying or cloning slot values
2403 from self to the new instance. If a slot value is an instance
2404 (satisfies @code{instance?}), it is cloned by calling @code{deep-clone}
2405 on that value. Other slot values are copied either as immediate values
2409 @node Write and Display
2410 @subsubsection Write and Display
2412 @deffn {primitive generic} write object port
2413 @deffnx {primitive generic} display object port
2414 When GOOPS is loaded, @code{write} and @code{display} become generic
2415 functions with special methods for printing
2419 objects - instances of the class @code{<object>}
2422 foreign objects - instances of the class @code{<foreign-object>}
2425 classes - instances of the class @code{<class>}
2428 generic functions - instances of the class @code{<generic>}
2431 methods - instances of the class @code{<method>}.
2434 @code{write} and @code{display} print non-GOOPS values in the same way
2435 as the Guile primitive @code{write} and @code{display} functions.
2438 @node MOP Specification
2439 @section MOP Specification
2441 For an introduction to metaobjects and the metaobject protocol,
2442 see @ref{Metaobjects and the Metaobject Protocol}.
2444 The aim of the MOP specification in this chapter is to specify all the
2445 customizable generic function invocations that can be made by the standard
2446 GOOPS syntax, procedures and methods, and to explain the protocol for
2447 customizing such invocations.
2449 A generic function invocation is customizable if the types of the arguments
2450 to which it is applied are not all determined by the lexical context in
2451 which the invocation appears. For example,
2455 the @code{(initialize @var{instance} @var{initargs})} invocation in the
2456 default @code{make-instance} method is customizable, because the type of the
2457 @code{@var{instance}} argument is determined by the class that was passed to
2458 @code{make-instance}.
2461 the @code{(make <generic> #:name ',name)} invocation in @code{define-generic}
2462 is not customizable, because all of its arguments have lexically determined
2466 When using this rule to decide whether a given generic function invocation
2467 is customizable, we ignore arguments that are expected to be handled in
2468 method definitions as a single ``rest'' list argument.
2470 For each customizable generic function invocation, the @dfn{invocation
2471 protocol} is explained by specifying
2475 what, conceptually, the applied method is intended to do
2478 what assumptions, if any, the caller makes about the applied method's side
2482 what the caller expects to get as the applied method's return value.
2486 * Class Definition::
2487 * Instance Creation::
2488 * Class Redefinition::
2489 * Method Definition::
2490 * Generic Function Invocation::
2493 @node Class Definition
2494 @subsection Class Definition
2496 @code{define-class} (syntax)
2500 @code{class} (syntax)
2504 @code{make-class} (procedure)
2508 @code{make @var{metaclass} @dots{}} (generic)
2510 @var{metaclass} is the metaclass of the class being defined, either
2511 taken from the @code{#:metaclass} class option or computed by
2512 @code{ensure-metaclass}. The applied method must create and return the
2513 fully initialized class metaobject for the new class definition.
2519 @code{class-redefinition @var{old-class} @var{new-class}} (generic)
2521 @code{define-class} calls @code{class-redefinition} if the variable
2522 specified by its first argument already held a GOOPS class definition.
2523 @var{old-class} and @var{new-class} are the old and new class metaobjects.
2524 The applied method should perform whatever is necessary to handle the
2525 redefinition, and should return the class metaobject that is to be bound
2526 to @code{define-class}'s variable. The default class redefinition
2527 protocol is described in @ref{Class Redefinition}.
2530 The @code{(make @var{metaclass} @dots{})} invocation above will create
2531 an class metaobject with metaclass @var{metaclass}. By default, this
2532 metaobject will be initialized by the @code{initialize} method that is
2533 specialized for instances of type @code{<class>}.
2535 @code{initialize <class> @var{initargs}} (method)
2539 @code{compute-cpl @var{class}} (generic)
2541 The applied method should compute and return the class precedence list
2542 for @var{class} as a list of class metaobjects. When @code{compute-cpl}
2543 is called, the following @var{class} metaobject slots have all been
2544 initialized: @code{name}, @code{direct-supers}, @code{direct-slots},
2545 @code{direct-subclasses} (empty), @code{direct-methods}. The value
2546 returned by @code{compute-cpl} will be stored in the @code{cpl} slot.
2549 @code{compute-slots @var{class}} (generic)
2551 The applied method should compute and return the slots (union of direct
2552 and inherited) for @var{class} as a list of slot definitions. When
2553 @code{compute-slots} is called, all the @var{class} metaobject slots
2554 mentioned for @code{compute-cpl} have been initialized, plus the
2555 following: @code{cpl}, @code{redefined} (@code{#f}), @code{environment}.
2556 The value returned by @code{compute-slots} will be stored in the
2560 @code{compute-get-n-set @var{class} @var{slot-def}} (generic)
2562 @code{initialize} calls @code{compute-get-n-set} for each slot computed
2563 by @code{compute-slots}. The applied method should compute and return a
2564 pair of closures that, respectively, get and set the value of the specified
2565 slot. The get closure should have arity 1 and expect a single argument
2566 that is the instance whose slot value is to be retrieved. The set closure
2567 should have arity 2 and expect two arguments, where the first argument is
2568 the instance whose slot value is to be set and the second argument is the
2569 new value for that slot. The closures should be returned in a two element
2570 list: @code{(list @var{get} @var{set})}.
2572 The closures returned by @code{compute-get-n-set} are stored as part of
2573 the value of the @var{class} metaobject's @code{getters-n-setters} slot.
2574 Specifically, the value of this slot is a list with the same number of
2575 elements as there are slots in the class, and each element looks either like
2578 @code{(@var{slot-name-symbol} @var{init-function} . @var{index})}
2584 @code{(@var{slot-name-symbol} @var{init-function} @var{get} @var{set})}
2587 Where the get and set closures are replaced by @var{index}, the slot is
2588 an instance slot and @var{index} is the slot's index in the underlying
2589 structure: GOOPS knows how to get and set the value of such slots and so
2590 does not need specially constructed get and set closures. Otherwise,
2591 @var{get} and @var{set} are the closures returned by @code{compute-get-n-set}.
2593 The structure of the @code{getters-n-setters} slot value is important when
2594 understanding the next customizable generic functions that @code{initialize}
2598 @code{compute-getter-method @var{class} @var{gns}} (generic)
2600 @code{initialize} calls @code{compute-getter-method} for each of the class's
2601 slots (as determined by @code{compute-slots}) that includes a
2602 @code{#:getter} or @code{#:accessor} slot option. @var{gns} is the
2603 element of the @var{class} metaobject's @code{getters-n-setters} slot that
2604 specifies how the slot in question is referenced and set, as described
2605 above under @code{compute-get-n-set}. The applied method should create
2606 and return a method that is specialized for instances of type @var{class}
2607 and uses the get closure to retrieve the slot's value. [ *fixme Need
2608 to insert something here about checking that the value is not unbound. ]
2609 @code{initialize} uses @code{add-method!} to add the returned method to
2610 the generic function named by the slot definition's @code{#:getter} or
2611 @code{#:accessor} option.
2614 @code{compute-setter-method @var{class} @var{gns}} (generic)
2616 @code{compute-setter-method} is invoked with the same arguments as
2617 @code{compute-getter-method}, for each of the class's slots that includes
2618 a @code{#:setter} or @code{#:accessor} slot option. The applied method
2619 should create and return a method that is specialized for instances of
2620 type @var{class} and uses the set closure to set the slot's value.
2621 @code{initialize} then uses @code{add-method!} to add the returned method
2622 to the generic function named by the slot definition's @code{#:setter}
2623 or @code{#:accessor} option.
2626 @node Instance Creation
2627 @subsection Instance Creation
2629 @code{make <class> . @var{initargs}} (method)
2633 @code{allocate-instance @var{class} @var{initargs}} (generic)
2635 The applied @code{allocate-instance} method should allocate storage for
2636 a new instance of class @var{class} and return the uninitialized instance.
2639 @code{initialize @var{instance} @var{initargs}} (generic)
2641 @var{instance} is the uninitialized instance returned by
2642 @code{allocate-instance}. The applied method should initialize the new
2643 instance in whatever sense is appropriate for its class. The method's
2644 return value is ignored.
2647 @node Class Redefinition
2648 @subsection Class Redefinition
2650 The default @code{class-redefinition} method, specialized for classes
2651 with the default metaclass @code{<class>}, has the following internal
2654 @code{class-redefinition (@var{old <class>}) (@var{new <class>})}
2659 @code{remove-class-accessors! @var{old}} (generic)
2662 @code{update-direct-method! @var{method} @var{old} @var{new}} (generic)
2665 @code{update-direct-subclass! @var{subclass} @var{old} @var{new}} (generic)
2668 This protocol cleans up things that the definition of the old class
2669 once changed and modifies things to work with the new class.
2671 The default @code{remove-class-accessors!} method removes the
2672 accessor methods of the old class from all classes which they
2675 The default @code{update-direct-method!} method substitutes the new
2676 class for the old in all methods specialized to the old class.
2678 The default @code{update-direct-subclass!} method invokes
2679 @code{class-redefinition} recursively to handle the redefinition of
2682 When a class is redefined, any existing instance of the redefined class
2683 will be modified for the new class definition before the next time that
2684 any of the instance's slot is referenced or set. GOOPS modifies each
2685 instance by calling the generic function @code{change-class}.
2687 The default @code{change-class} method copies slot values from the old
2688 to the modified instance, and initializes new slots, as described in
2689 @ref{Changing the Class of an Instance}. After doing so, it makes a
2690 generic function invocation that can be used to customize the instance
2693 @code{change-class (@var{old-instance <object>}) (@var{new <class>})} (method)
2697 @code{update-instance-for-different-class @var{old-instance} @var{new-instance}} (generic)
2699 @code{change-class} invokes @code{update-instance-for-different-class}
2700 as the last thing that it does before returning. The applied method can
2701 make any further adjustments to @var{new-instance} that are required to
2702 complete or modify the change of class. The return value from the
2703 applied method is ignored.
2705 The default @code{update-instance-for-different-class} method does
2709 @node Method Definition
2710 @subsection Method Definition
2712 @code{define-method} (syntax)
2716 @code{add-method! @var{target} @var{method}} (generic)
2718 @code{define-method} invokes the @code{add-method!} generic function to
2719 handle adding the new method to a variety of possible targets. GOOPS
2720 includes methods to handle @var{target} as
2724 a generic function (the most common case)
2730 a primitive generic (@pxref{Extending Guiles Primitives})
2733 By defining further methods for @code{add-method!}, you can
2734 theoretically handle adding methods to further types of target.
2737 @node Generic Function Invocation
2738 @subsection Generic Function Invocation
2740 [ *fixme* Description required here. ]
2742 @code{apply-generic}
2749 @code{compute-applicable-methods}
2752 @code{sort-applicable-methods}
2755 @code{apply-methods}
2758 @code{no-applicable-method}
2761 @code{sort-applicable-methods}
2765 @code{method-more-specific?}
2768 @code{apply-methods}
2779 @code{no-next-method}