object@name
object@name <- value
slot(object, name)
slot(object, name, check = TRUE) <- value
.hasSlot(object, name)
slotNames(x)
getSlots(x)., it
needs to be quoted (by backticks or single or double quotes). In the case of the slot function, name can be any
expression that evaluates to a valid slot in the class definition.
Generally, the only reason to use the functional form rather than
the simpler operator is because the slot name has to be computed.
slot, a flag. If
TRUE, check the assigned value for validity
as the value of this slot. User's coded should not set this to
FALSE in normal use, since the resulting object can be invalid.
slotNames (only) uses class(x)
instead."@" operator and the slot function extract or
replace the formally defined slots for the object.Functions slotNames and getSlots return respectively the
names of the slots and the classes associated with the slots in the
specified class definition. Except for its extended interpretation of
x (above), slotNames(x) is just names(getSlots(x)).
Unlike general attributes, slots are not partially matched, and asking for (or trying to set) a slot with an invalid name for that class generates an error.
The @ extraction operator and slot
function themselves do no checking against the class definition,
simply matching the name in the object itself.
The replacement forms do check (except for slot in the case
check=FALSE). So long as slots are set without cheating, the
extracted slots will be valid.
Be aware that there are two ways to cheat, both to be avoided but
with no guarantees. The obvious way is to assign a slot with
check=FALSE. Also, slots in R are implemented as
attributes, for the sake of some back compatibility. The current
implementation does not prevent attributes being assigned, via
attr<-, and such assignments are not checked for
legitimate slot names.
Note that the "@" operators for extraction and (since R 3.0.0)
replacement are primitive and actually reside in the base
package.
The replacement versions of "@" and slot() differ in
the computations done to coerce the right side of the assignment to
the declared class of the slot. Both verify that the value provided
is from a subclass of the declared slot class. The slot()
version will go on to call the coerce method if there is one, in
effect doing the computation as(value, slotClass, strict =
FALSE). The "@" version just verifies the relation,
leaving any coerce to be done later (e.g., when a relevant method is
dispatched).
In most uses the result is equivalent, and the "@" version
saves an extra function call, but if empirical evidence shows that a
conversion is needed, either call as() before the replacement
or use the replacement version of slot().
Chambers, John M. (1998) Programming with Data Springer (For the original S4 version.)
@,
Classes,
Methods,
getClass,
names.
setClass("track", representation(x="numeric", y="numeric"))
myTrack <- new("track", x = -4:4, y = exp(-4:4))
slot(myTrack, "x")
slot(myTrack, "y") <- log(slot(myTrack, "y"))
utils::str(myTrack)
getSlots("track") # or
getSlots(getClass("track"))
slotNames(class(myTrack)) # is the same as
slotNames(myTrack)
Run the code above in your browser using DataLab