classRepresentation
.new
, the virtual classes, in fact a
very important programming tool. They are used to group together
ordinary classes that want to share some programming behavior,
without necessarily restricting how the behavior is implemented.
Virtual class definitions may if you want include
slots (to provide some common behavior without fully defining
the object---see the class traceable
for an example). A simple and useful form of virtual class is the class
union, a virtual class that is defined in a call to
setClassUnion
by listing one or
more of subclasses (classes that extend the class union). Class
unions can include as subclasses basic object types (whose
definition is otherwise sealed).
There are a number of "numeric"
is a class corresponding to numeric vectors.
The other vector basic classes are "logical"
, "integer"
,
"complex"
, "character"
, "raw"
, "list"
and "expression"
.
The prototypes for
the vector classes are vectors of length 0 of the corresponding
type. Notice that basic classes are unusual in that the
prototype object is from the class itself.
In addition to the vector classes there are also basic classes
corresponding to objects in the
language, such as "function"
and "call"
.
These classes are subclasses of the virtual class "language"
.
Finally, there are object types and corresponding basic classes for
"environment"
and
"externalptr"
.
These objects do not follow the
functional behavior of the language; in particular, they are not
copied and so cannot have attributes or slots defined locally.
All these classes can be used as slots or as superclasses for any other class definitions, although they do not themselves come with an explicit class. For the abnormal object types, a special mechanism is used to enable inheritance as described below.
contains=
argument to setClass
. Three groups
of such classes behave distinctly:
setOldClass
(you can check that this has been done
by callinggetClass
, which should return a class that
extendsenvironment
that can not be used directly as a type
for an S4 object. See
below.matrix
andarray
, implying objects with
arbitrary vector types plus thedim
anddimnames
attributes.This section describes the approach to combining S4 computations with older S3 computations by using such classes as superclasses. The design goal is to allow the S4 class to inherit S3 methods and default computations in as consistent a form as possible.
As part of a general effort to make the S4 and S3 code in R more
consistent, when objects from an S4 class are used as the first
argument to a non-default S3 method, either for an S3 generic function
(one that calls UseMethod
) or for one of the primitive
functions that dispatches S3 methods, an effort is made to provide a
valid object for that method. In particular, if the S4 class extends
an S3 class or matrix
or array
, and there is an S3
method matching one of these classes, the S4 object will be coerced to
a valid S3 object, to the extent that is possible given that there is
no formal definition of an S3 class.
For example, suppose "myFrame"
is an S4 class that includes the
S3 class "data.frame"
in the contains=
argument to
setClass
. If an object from this S4 class is passed to
a function, say as.matrix
, that has an S3 method for
"data.frame"
, the internal code for UseMethod
will convert the object to a data frame; in particular, to an S3
object whose class attribute will be the vector corresponding to the
S3 class (possibly containing multiple class names). Similarly for an
S4 object inheriting from "matrix"
or "array"
, the S4
object will be converted to a valid S3 matrix or array.
Note that the conversion is not applied when an S4 object is
passed to the default S3 method. Some S3 generics attempt to deal
with general objects, including S4 objects. Also, no transformation
is applied to S4 objects that do not correspond to a selected S3
method; in particular, to objects from a class that does not contain
either an S3 class or one of the basic types. See asS4
for the transformation details.
In addition to explicit S3 generic functions, S3 methods are defined for a variety of operators and functions implemented as primitives. These methods are dispatched by some internal C code that operates partly through the same code as real S3 generic functions and partly via special considerations (for example, both arguments to a binary operator are examined when looking for methods). The same mechanism for adapting S4 objects to S3 methods has been applied to these computations as well, with a few exceptions such as generating an error if an S4 object that does not extend an appropriate S3 class or type is passed to a binary operator.
The remainder of this section discusses the mechanisms for
inheriting from basic object types. See
or
for inhering from the matrix and array
pseudo-classes, or from time-series. For the
corresponding details for inheritance
from S3 classes, see setOldClass
.
An object from a class that directly and simply contains one
of the basic object types in R, has implicitly a corresponding
.Data
slot of that type, allowing computations to extract
or replace the data part while leaving other slots
unchanged. If the type is one that can accept attributes and is
duplicated normally, the inheritance also determines the type of the
object; if the class definition has a .Data
slot
corresponding to a normal type, the class of the
slot determines the type of the object (that is, the value of
typeof(x)
).
For such classes, .Data
is a pseudo-slot; that
is, extracting or setting it modifies the non-slot data in the
object. The functions getDataPart
and
setDataPart
are a cleaner, but essentially
equivalent way to deal with the data part.
Extending a basic type this way allows objects to
use old-style code for the corresponding type as well as S4
methods. Any basic type can be used for .Data
, but
a few types are treated differently because they do not behave like ordinary objects;
for example, "NULL"
, environments, and external pointers.
Classes extend these types by having a slot, .xData
,
itself inherited from an internally defined S4 class. This
slot actually contains an object of the inherited type, to
protect computations from the reference semantics of the type.
Coercing to the nonstandard object type then requires an
actual computation, rather than the "simple"
inclusion
for other types and classes. The intent is that programmers
will not need to take account of the mechanism, but one
implication is that you should not explicitly use the
type of an S4 object to detect inheritance from an arbitrary
object type. Use
is
and similar functions instead.
Chambers, John M. (1998) Programming with Data Springer (For the original S4 version.)
Chambers, John M. and Hastie, Trevor J. eds (1992) Statistical Models in S. Wadsworth & Brooks/Cole (Appendix A for S3 classes.)
Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) The New S Language. Wadsworth & Brooks/Cole. (Out of print.) (The description of vectors, matrix, array and time-series objects.)
Methods
for analogous discussion of methods,
setClass
for details of specifying class definitions,
is
,
as
,
new
,
slot