Goops Manual (original) (raw)

Node:Slot Options, Next:Class Definition Internals, Previous:Class Options, Up:Defining New Classes


3.2.3 Slot Options

#:allocation allocation slot option

The #:allocation option tells GOOPS how to allocate storage for the slot. Possible values for allocation are

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 forcompute-get-n-set that is specialized for the new metaclass. For an example of how to do this, see Customizing Class Definition.

#:slot-ref getter slot option
#:slot-set! setter slot option

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.

#:getter getter slot option
#:setter setter slot option
#:accessor accessor slot option

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

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.

#:init-value init-value slot option
#:init-form init-form slot option
#:init-thunk init-thunk slot option
#:init-keyword init-keyword slot option

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

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 ) 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 callnext-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.