Objects and Classes

The S3 system has a straightforward approach to object orientation. It lets us associate classes with any object (except for NULL). Classes are text strings with no structure, and you can get the classes associated with an object by calling the function class.

class(4)

## [1] "numeric"

class("foo")

## [1] "character"

class(TRUE)

## [1] "logical"

class(sin)

## [1] "function"

You can set the class of an object with the corresponding assignment function, shown here:

class(sin) <- "foo"
class(sin)

## [1] "foo"

without affecting what the object is or does.

sin(0)

## [1] 0

There are some limits to which objects you can change the class of—you cannot change the class of literal numbers and strings, for example, so if you attempted this:

class(2) <- "character"
class("foo") <- "numeric"

you would get errors. Still, you are free to modify the classes of objects any time you want. The class associated with an object is just an attribute containing one or more class names—in the previous cases, all the objects have a single class, but the matrix expressions we created Chapter 2, for example, had multiple classes. Vectors of class names are used both for multiple inheritance and for single inheritance, and there is no formal class structure at all. You can set the classes any way you want. The class attribute is just a vector of strings that are interpreted as class names.

The only thing that makes the class attribute interesting, compared to any other attributes you could associate with objects, is how it is used for dispatching generic functions. When you call a generic function, the actual function that gets called depends on the class of one of its arguments, usually the first (if you do not provide the argument explicitly, it will always be the first).

Generic Functions

The generic function mechanism in the S3 system is implemented in the UseMethod and NextMethod functions. To define a generic function, foo, you would, for example, write the following:

foo <- function(x, y, z) UseMethod("foo")

Calling foo would then invoke UseMethod that would search for concrete implementations of foo. Such functions are identified by their name alone—any function whose name starts with foo. is considered an implementation of foo, and the one that will be chosen depends on the class of the argument x. We haven’t done any implementations of foo yet, so calling the function will just give us an error for now.

foo(1, 2, 3)

## Error in UseMethod("foo"): no applicable method for 'foo' applied to an object of class "c('double', 'numeric')"

However, we can make a default implementation. The default implementation for a generic function—the one that will be used if UseMethod can find no better matching implementation—has a name that ends with .default. We can implement the following:

foo.default <- function(x, y, z) {
   cat("default foo
")
}

and this function will be invoked if we call foo with an object that doesn’t have a better implementation.

foo(1, 2, 3)

## default foo

To specialize a generic function to specific classes, we just have to define functions with appropriate names. Any function name that begins with foo. can be used and will be called if we call foo with an object of the appropriate class. To specialize foo to numeric values, for example, we could write the following:

foo.numeric <- function(x, y, z) {
   cat("numeric
")
}

Now the following function will be called if x is numeric.

foo(1, 2, 3)

## numeric

A quick note before we continue to explore how dispatching is done on generic functions for user-defined classes: when we used UseMethod in the definition of foo, we called it with the name foo. This is why it looks for that name when it searches for implementations of the generic function. We could have asked it to search for other functions. The name we gave the generic function when we defined foo is not what determines what we search for when we call the function—that is determined by the name we give UseMethod. Further, we have seen it dispatches on the first argument of foo, but this is just a default. We could give UseMethod another object to dispatch on.

bar <- function(x, y, z) UseMethod("foo", y)

I do not recommend doing this—it goes against the conventions used in R—but it is possible, and with this function, we would dispatch on the y argument (and search for the generic function foo, not bar).

foo("foo",2,3)

## default foo

bar("foo",2,3)

## numeric

bar(1,"bar",3)

## default foo

Going back to the rules for dispatching, when UseMethod is called, it starts to search for functions based on their name. It will take the classes of an object and search those in order. If it doesn’t find any matching function, it will call the default, if it exists.

So, let’s consider again foo where we have a numeric and a default implementation.

x <- 1
foo(x, 2, 3)

## numeric

Here, we have created the object x that is numeric, so when we call foo, we match the numeric function. But we can change the class of x and see what happens.

class(x) <- c("a", "b", "c")
foo(x, 2, 3)

## default foo

Now, since x has the classes a, b, and c but not numeric, UseMethod does not find the numeric version but hits the default one. We can, of course, define functions for the other classes and see what happens.

foo.a <- function(x, y, z) cat("a
")
foo.b <- function(x, y, z) cat("b
")
foo.c <- function(x, y, z) cat("c
")
foo(x, 2, 3)

## a

Because we now have functions for x’s classes, we can find them, and because a is the first class, that is the one that will be called. If we change the order of x’s classes, we call the other functions— UseMethod always calls the first it finds.

class(x) <- c("b", "a", "c")
foo(x, 2, 3)

## b

class(x) <- c("c", "b", "a")
foo(x, 2, 3)

## c

When calling UseMethod, we will find and call the first matching function. The related NextMethod function can be invoked to find and call the next function in the chain of classes. To see it in action, we can redefine the three a, b, and c foo implementations and make them call the next function in line.

foo.a <- function(x, y, z) {
  cat("a
")
  NextMethod()
}
foo.b <- function(x, y, z) {
  cat("b
")
  NextMethod()
}
foo.c <- function(x, y, z) {
  cat("c
")
  NextMethod()
}

They will all call the next function in line, and since we have a default implementation of foo, the last in line will call that one. The order in which the functions are called depends entirely on the order of x’s classes.

class(x) <- c("a", "b", "c")
foo(x, 2, 3)

## a
## b
## c
## default foo

class(x) <- c("b", "a", "c")
foo(x, 2, 3)

## b
## a
## c
## default foo

class(x) <- c("c", "b", "a")
foo(x, 2, 3)

## c
## b
## a
## default foo

This generic dispatch mechanism is extremely flexible, so it will require some discipline to ensure a robust object-oriented design. To implement domain-specific languages, though, we are interested in how we can use it to add operators to our language.

Operator Overloading

Most operators, with exceptions of arrow assignments (<- and ->) and slot and component access (@ and $), behave as generic functions and can be overloaded. The mechanism for overloading operators is not different from the mechanism for implementing a new version of a generic function—if you name a function the right way, it will be invoked when a generic function is called.

For example, to define addition on a objects, we need to define the +.a, which we could do like this:

`+.a` <- function(e1, e2) {
  cat("+.a
")
  NextMethod()
}
x + 2

## +.a

## [1] 3
## attr(,"class")
## [1] "c" "b" "a"

Here, we print some output and then invoke the underlying numeric addition—since the object x here is a numeric value as well as an object of class a—by invoking NextMethod. It is important that we use NextMethod here. If we use addition, we would be calling +.a once again. So do not attempt this:

`+.a` <- function(e1, e2) {
  cat("+.a
")
  e1 + e2
}

This function causes infinite recursion, and it is not what you want.

You overload operators in the same way as you would define specializations of generic functions, but there are differences between the two and how they dispatch. With standard generic functions, you would dispatch based on the first argument. With operators, there are heuristics that are there to make sure that the same function is called regardless of the order of the operands. You could easily imagine the pain to debug programs where switching the order of the operands would also call entirely different functions. That doesn’t happen in R because operations are not exactly the same as other generic functions.

If we have defined +.a and we try to add a number to x, then we can do that in either order, and it will be the +.a function that is called.

x + 3

## +.a

## [1] 4
## attr(,"class")
## [1] "c" "b" "a"

3 + x

## +.a

## [1] 4
## attr(,"class")
## [1] "c" "b" "a"

This is also the case if we add to x an object of a different class.

x <- 1 ; y <- 3
class(x) <- "a"
class(y) <- "b"
x + y

## +.a

## [1] 4
## attr(,"class")
## [1] "a"

y + x

## +.a

## [1] 4
## attr(,"class")
## [1] "b"

unless we have also defined an addition operator for that class.

`+.b` <- function(e1, e2) {
  cat("+.bn")
  NextMethod()
}

x + y

## Warning: Incompatible methods ("+.a", "+.b") for
## "+"

## [1] 4
## attr(,"class")
## [1] "a"

y + x

## Warning: Incompatible methods ("+.b", "+.a") for
## "+"

## [1] 4
## attr(,"class")
## [1] "b"

If both a and b have their own version of addition, then we need a way to resolve which version x+y and y+x should call. Here, the first operand takes precedence, so it determines which function is called—and you get a well-deserved warning for getting up to such shenanigans.

You might be able to come up with other rules on how to resolve such situations. For example, you could say that the most abstract method should be called, so if both x and y were of class b but only x was also of class a, then we should call +.b.

class(x) <- c("a","b")
class(y) <- "b"

Unfortunately, you cannot make such rules in the S3 system. It is possible with the S4 system, where you can dispatch generic functions based on multiple arguments, but that goes beyond the scope of this book. We will make sure to avoid situations where we have to add different classes of objects that define the same operators by constructing grammars appropriately.

Notice, though, that the combination of multiple classes and NextMethod still works as before. In the S3 system, we cannot define generic methods that dispatch based on multiple arguments, but we can use NextMethod to invoke several methods as we evaluate an operator. If we invoke +.a on object x, which now has classes a and b, the call to NextMethod in the implementation of that function will invoke +.b before that function invokes the numeric addition.

class(x) <- c("a", "b")
x + 2

## +.a
## +.bn

## [1] 3
## attr(,"class")
## [1] "a" "b"

x + y

## Warning: Incompatible methods ("+.a", "+.b") for
## "+"

## [1] 4
## attr(,"class")
## [1] "a" "b"

R has unary operators as well as binary operators. The negation operator, !, only exists in a unary operator, and you can specialize it for a given class by defining a function that takes a single argument.

`!.a` <- function(x) {
  cat("Not for a
")
  NextMethod()
}
!x

## Not for a

## [1] FALSE

For the - and + operators, though, we use the same symbol for both unary and binary operators. Here, we have to use the same function for both since the only way we identify operator functions is through their name, and that would be the same for the unary and binary operators. The way we can determine whether the function is called as part of a unary or binary operator is to test whether the second argument is missing. If it is, we have a unary operator; otherwise, it is binary.

`+.a` <- function(e1, e2) {
  if (missing(e2)) {
    cat("Unary
")
  } else {
    cat("Binary
")
  }
  NextMethod()
}

class(x) <- "a"
+x

## Unary

## [1] 1
## attr(,"class")
## [1] "a"

2+x

## Binary

## [1] 3
## attr(,"class")
## [1] "a"

Group Generics

There is another way you can overload operators based on their operands’ class: group generics. Group generics, as the name suggests, group several operators. They provide a way for us to define a single function that handles all operators of a given type. For arithmetic and logical operators (+, -, *, /, ^, %%, %/%, &, |, !, ==, !=, <, <=, >=, and >), the relevant group generic is Ops.

If we define Ops.c, then we define a function that will be called for all of these operators when used on an element of class c.

Ops.c <- function(e1, e2) {
  cat(paste0("Ops.c (", .Generic, ")
"))
  NextMethod()
}

z <- 2
class(z) <- "c"
z + 1

## Ops.c (+)

## [1] 3
## attr(,"class")
## [1] "c"

1 + z

## Ops.c (+)

## [1] 3
## attr(,"class")
## [1] "c"

z ^ 3

## Ops.c (^)

## [1] 8
## attr(,"class")
## [1] "c"

The “magical” variable . Generic contains the name of the operator that is called, and calling NextMethod will dispatch to the relevant next implementation of the operator.

If you implement both the Ops group generic and concrete implementations of some individual operator generics, then the latter takes precedence. If, for example, we have an object of class a and c, where we have defined addition for class a and have the group generic for c, the addition will invoke the +.a function. All other operators will invoke the Ops.c function.

class(z) <- c("a", "c")
1 + z

## Binary

## [1] 3
## attr(,"class")
## [1] "a" "c"

2 * z

## Ops.c (*)

## [1] 4
## attr(,"class")
## [1] "a" "c"

With Ops you have a method for catching all operators for which you do not explicitly write specialized generics.