(goops.info.gz) Slot Options

Info Catalog

(goops.info.gz) Class Options

(goops.info.gz) Defining New Classes

(goops.info.gz) Class Definition Internals

 
 Slot Options
 ------------
 
  - slot option: #:allocation allocation
      The `#:allocation' option tells GOOPS how to allocate storage for
      the slot.  Possible values for ALLOCATION are
 
         * `#:instance'
 
           Indicates that GOOPS should create separate storage for this
           slot in each new instance of the containing class (and its
           subclasses).
 
         * `#:class'
 
           Indicates that GOOPS should create storage for this slot that
           is shared by all instances of the containing class (and its
           subclasses).  In other words, a slot in class C with
           allocation `#:class' is shared by all INSTANCEs for which
           `(is-a? INSTANCE C)'.
 
         * `#:each-subclass'
 
           Indicates that GOOPS should create storage for this slot that
           is shared by all _direct_ instances of the containing class,
           and that whenever a subclass of the containing class is
           defined, GOOPS should create a new storage for the slot that
           is shared by all _direct_ instances of the subclass.  In
           other words, a slot with allocation `#:each-subclass' is
           shared by all instances with the same `class-of'.
 
         * `#:virtual'
 
           Indicates that GOOPS should not allocate storage for this
           slot.  The slot definition must also include the `#:slot-ref'
           and `#:slot-set!' options to specify how to reference and set
           the value for this slot.
 
      The default value is `#:instance'.
 
      Slot allocation options are processed when defining a new class by
      the generic function `compute-get-n-set', which is specialized by
      the class's metaclass.  Hence new types of slot allocation can be
      implemented by defining a new metaclass and a method for
      `compute-get-n-set' that is specialized for the new metaclass.  For
      an example of how to do this, see  Customizing Class
      Definition.
 
  - slot option: #:slot-ref getter
  - slot option: #:slot-set! setter
      The `#:slot-ref' and `#:slot-set!' options must be specified if
      the slot allocation is `#:virtual', and are ignored otherwise.
 
      GETTER should be a closure taking a single INSTANCE parameter that
      returns the current slot value.  SETTER should be a closure taking
      two parameters - INSTANCE and NEW-VAL - that sets the slot value
      to NEW-VAL.
 
  - slot option: #:getter getter
  - slot option: #:setter setter
  - slot option: #:accessor accessor
      These options, if present, tell GOOPS to create generic function
      and method definitions that can be used to get and set the slot
      value more conveniently than by using `slot-ref' and `slot-set!'.
 
      GETTER specifies a generic function to which GOOPS will add a
      method for getting the slot value.  SETTER specifies a generic
      function to which GOOPS will add a method for setting the slot
      value.  ACCESSOR specifies an accessor to which GOOPS will add
      methods for both getting and setting the slot value.
 
      So if a class includes a slot definition like this:
 
           (c #:getter get-count #:setter set-count #:accessor count)
 
      GOOPS defines generic function methods such that the slot value
      can be referenced using either the getter or the accessor -
 
           (let ((current-count (get-count obj))) ...)
           (let ((current-count (count obj))) ...)
 
      - and set using either the setter or the accessor -
 
           (set-count obj (+ 1 current-count))
           (set! (count obj) (+ 1 current-count))
 
      Note that
 
         * with an accessor, the slot value is set using the generalized
           `set!' syntax
 
         * in practice, it is unusual for a slot to use all three of
           these options: read-only, write-only and read-write slots
           would typically use only `#:getter', `#:setter' and
           `#:accessor' options respectively.
 
      If the specified names are already bound in the top-level
      environment to values that cannot be upgraded to generic
      functions, those values are overwritten during evaluation of the
      `define-class' that contains the slot definition.  For details,
      see  ensure-generic Generic Function Internals.
 
  - slot option: #:init-value init-value
  - slot option: #:init-form init-form
  - slot option: #:init-thunk init-thunk
  - slot option: #:init-keyword init-keyword
      These options provide various ways to specify how to initialize the
      slot's value at instance creation time.  INIT-VALUE is a fixed
      value.  INIT-THUNK is a procedure of no arguments that is called
      when a new instance is created and should return the desired
      initial slot value.  INIT-FORM is an unevaluated expression that
      gets evaluated when a new instance is created and should return
      the desired initial slot value.  INIT-KEYWORD is a keyword that
      can be used to pass an initial slot value to `make' when creating
      a new instance.
 
      If more than one of these options is specified for the same slot,
      the order of precedence, highest first is
 
         * `#:init-keyword', if INIT-KEYWORD is present in the options
           passed to `make'
 
         * `#:init-thunk', `#:init-form' or `#:init-value'.
 
      If the slot definition contains more than one initialization
      option of the same precedence, the later ones are ignored.  If a
      slot is not initialized at all, its value is unbound.
 
      In general, slots that are shared between more than one instance
      are only initialized at new instance creation time if the slot
      value is unbound at that time.  However, if the new instance
      creation specifies a valid init keyword and value for a shared
      slot, the slot is re-initialized regardless of its previous value.
 
      Note, however, that the power of GOOPS' metaobject protocol means
      that everything written here may be customized or overridden for
      particular classes!  The slot initializations described here are
      performed by the least specialized method of the generic function
      `initialize', whose signature is
 
           (define-method (initialize (object <object>) initargs) ...)
 
      The initialization of instances of any given class can be
      customized by defining a `initialize' method that is specialized
      for that class, and the author of the specialized method may
      decide to call `next-method' - which will result in a call to the
      next less specialized `initialize' method - at any point within the
      specialized code, or maybe not at all.  In general, therefore, the
      initialization mechanisms described here may be modified or
      overridden by more specialized code, or may not be supported at
      all for particular classes.
 

Info Catalog

(goops.info.gz) Class Options

(goops.info.gz) Defining New Classes

(goops.info.gz) Class Definition Internals