Setup

library(tibble); library(dplyr) 
library(ggplot2); library(R6)

Regular polygons, first take

triangle_size <- 6
square_size   <- 4
hexagon_size  <- 5

A common distinguishing feature: size

triangle <- list(size = 6)
square   <- list(size = 4)
hexagon  <- list(size = 5)

Size alone is not sufficient:

x <- list(size = 6)

# is x a square or a triangle?

Adding sides

triangle <- list(sides = 3, size = 6)
square   <- list(sides = 4, size = 4)
hexagon  <- list(sides = 6, size = 5)

Let’s implement a print function:

print_rp <- function(rp) {    # hmm... the 'print' name is taken
    cat("Regular polygon with", rp$sides, 
        "sides of size", rp$size, "\n")
}

print_rp(triangle)

## Regular polygon with 3 sides of size 6

Nice!

A readable representation of the object is always welcome!

Let’s implement resize():

resize <- function(rp, value = 1) {
    rp$size <- rp$size * value
    rp
}

print_rp(resize(triangle, 2))

## Regular polygon with 3 sides of size 12

print_rp(triangle)  # the original object is unchanged

## Regular polygon with 3 sides of size 6

Congratulations, we have a rudimentary OO model!

Anything missing?

How do I add a circle to the collection?

• Circles are distant relatives of Regular Polygons
  • common elements like size
  • different elements such as sides and print_rp()
• This is Inheritance

I would love to use print() instead of print_rp()!

• This is Polymorphism

Better: use class()

class(square) <- "regular_polygon"
class(square)

## [1] "regular_polygon"

class(hexagon) <- "regular_polygon"
class(hexagon)

## [1] "regular_polygon"

Let’s look at the code for print()

print

## function (x, ...) 
## UseMethod("print")
## <bytecode: 0x000000001d0d0100>
## <environment: namespace:base>

UseMethod() is the dispatcher!

From ?UseMethod:

Method dispatch takes place based on the class(es) of the first argument to the generic function or of the object supplied as an argument to UseMethod

• Specific print methods are named print.class_name(), etc.
• print() calls the right method based on the class of the first argument
• How many “prints” are there?

methods(print)

# ...
# [70] print.data.frame                                  
# [71] print.Date                                        
# [72] print.default
# ...
# [128] print.lm*        <- * means non-visible
# ...
# [221] print.tbl_df*
# ...

Yeah? … I want a print() method too!

• The generic print() takes care of the dispatch
• All I need to do is to define print.regular_polygon()

print.regular_polygon <- function(rp) {
    cat("Regular polygon with", rp$sides, 
        "sides of size", rp$size, "\n")
}

print(triangle)

## Regular polygon with 3 sides of size 6

Success!

What methods are available for my regular_polygon?

methods(class = "regular_polygon")

## [1] print
## see '?methods' for accessing help and source code

I want a resize() method!

Is there a resize() generic to take care of the dispatch?

methods(resize)

## no methods found

Define the generic (it will overwrite the previous resize() function)

resize <- function(x, ...) UseMethod("resize", x)   # only one argument

resize.regular_polygon <- function(rp, value = 1) {
    rp$size <- rp$size * value
    rp
}

Testing with printing

print(resize(triangle, 2))

## Regular polygon with 3 sides of size 12

This takes care of Polymorphism. What about Inheritance?

circle <- list(sides = NA, size = 1)
class(circle) <- c('circle', 'regular_polygon')
print(circle)

## Regular polygon with NA sides of size 1

circle inherited everything from regular_polygon; define own print.

print.circle <- function(rp) {
    cat("Circle of size", rp$size, "\n")
}
print(circle)

## Circle of size 1

Better!

Check inheritance

inherits(circle, 'circle')

## [1] TRUE

inherits(circle, 'regular_polygon')

## [1] TRUE

Resize works by calling resize of the parent class

print(resize(circle, 2))

## Circle of size 2

(there are more details but we skip them today)

But wait …

You mean I can just take over objects, assign them any class?

class(model)

## [1] "lm"

class(model) <- c("Agent Smith", class(model))
class(model)

## [1] "Agent Smith" "lm"

class(df1)

## [1] "data.frame"

class(df1) <- c("Agent Smith", class(df1))
class(df1)

## [1] "Agent Smith" "data.frame"

This code was responsible for Agent Smith taking over in Matrix Revolutions*

_{*not a true fact}

Use new(), must name the arguments

circle <- new("Circle", size = 1.5)
circle

## An object of class "Circle"
## Slot "size":
## [1] 1.5

Type checking works

circle2 <- new("Circle", size = "1.5")
# Error in validObject(.Object) :
#  invalid class “Circle” object: invalid object for slot 
# "size" in class "Circle": got class "character", 
# should be or extend class "numeric"

circle@size <- 1.7  # you should do this only inside of a class method
circle@size

## [1] 1.7

Type checking works again

circle@size <- "1.7"
# Error in (function (cl, name, valueClass)  : 
#  assignment of an object of class “character” is not valid for 
# @‘size’ in an object of class “Circle”; 
# is(value, "numeric") is not TRUE

• S4 printing is using the show() method; we need to overwrite it
  
• Use setMethod() with a function (which can be anonymous)

Circle_show <- function(object) {
    cat("Circle of size", object@size, "\n")
}

setMethod("show", "Circle", Circle_show)

## [1] "show"

print(circle)

## Circle of size 1.7

• We want additional constraints, e.g., @size should be positive
• Additional validity is provided by a function we must supply
• Add validity within setClass() or by using setValidity()
  • return either TRUE or an error message

Circle_validity <- function(object) {
    if (object@size < 0) return("Size must be positive")
    TRUE   # return TRUE if all tests pass
}

setValidity("Circle", Circle_validity)

circle2 <- new("Circle", size = -5)
# Error in validObject(.Object) : 
#  invalid class “Circle” object: Size must be positive

Modifying an existing S4 object is still permitted!!

circle@size <- -5
circle

## Circle of size -5

Force validity check

validObject(circle)
# Error in validObject(circle) : 
#  invalid class “Circle” object: Size must be positive

Make the circle nice again

circle@size <- 1.7

• It’s not a good idea to directly modify slots outside the object
• We will define accessor methods (since we are formal and all)
  • need to define the generic first setGeneric()
  • standardGeneric() used for S4 dispatching

Circle_get_size <- function(object) object@size

setGeneric(name = "size", 
           def = function(object) standardGeneric("size"),
           valueClass = "numeric")
setMethod("size", "Circle", Circle_get_size)

size(circle)

## [1] 1.7

Circle_set_size <- function(object, value) {
    object@size <- value     # modifies the object in the local scope
    validObject(object)      # force validation
    object                   # the setter must return the object
}

setGeneric(name = "size<-", 
           def = function(object, value) standardGeneric("size<-"))
setMethod("size<-", "Circle", Circle_set_size)

Let’s test it:

size(circle) <- 2.5
size(circle)

## [1] 2.5

Let’s have RegularPolygon inherit from Circle

• need to add a slot for sides

setClass(
    Class = "RegularPolygon",
    slots = representation(sides = "integer"), # only the new slot
    contains = "Circle"     # size inherited from Circle
)

triangle <- new("RegularPolygon", sides = 3L, size = 3.5)
print(triangle)

## Circle of size 3.5

Bummer!

Override show() for RegularPolygon

RegularPolygon_show <- function(object) {
    cat("Regular polygon with", object@sides, 
        "sides of size", object@size, "\n")    
}

setMethod("show", "RegularPolygon", RegularPolygon_show)

## [1] "show"

print(triangle)

## Regular polygon with 3 sides of size 3.5

• Possible conflicts among multiple setGeneric() functions
• Pollution of the namespace with extra generics
• Difficult to debug
• Type checking
  • works well only with simple data types
    • 'numeric' means 1.5 but also c(1, 2, 3)
    • in most cases one needs to define a validity function
  • made irrelevant if the data type is list
  • for data frames, it matters what is inside the data frame

Frank Harrell (author of Hmisc and “problems with stepwise regression”):

“If you love computer science more than you value your own time, use S4”

Except Environments:

• Similar to a list where each element is accessed by reference
• No new environment will be created at copy
• The old object is gone at re-assignment

my_env <- new.env()
my_env$x <- 42
ls(my_env)

## [1] "x"

my_env$x

## [1] 42

• We can set a slot to be an environment
• Need to define an initialize() method, called by new()
  • each new object initializes its own environment

setClass("Element",
         slots = representation(x = 'numeric', my_env = 'environment')
)

setMethod("initialize", "Element",
  function(.Object, ..., x=numeric(), my_env = new.env()) {
    callNextMethod(.Object, x = x, my_env = my_env, ...)
  }
)

el <- new("Element", x = 3)
print(el)

## An object of class "Element"
## Slot "x":
## [1] 3
## 
## Slot "my_env":
## <environment: 0x000000001d49e960>

el@my_env$a <- 1
print(el@my_env$a)

## [1] 1

Sometimes we want mutability, e.g., for bidirectional relationships

Alternative: Reference Classes

Reference Classes == S4 + Environment Trick + syntactic sugar

• Sometimes called R5, but this name causes confusion
• RC objects are mutable, they don’t use copy-on-change
• Use $ to access methods; looks like Java and Python
• Still a hack, but a hidden hack
• It is rather slow

Let’s skip Reference Classes! (that was fast!)

Access the object attributes

circle$size

## [1] 6.1

Access the object methods

circle$expand(2)         # look, no assignment
print(circle)

## Circle of size 12.2

private_circle <- PrivateCircle$new(6.6)
private_circle$hidden_size  # not visible

## NULL

private_circle$size         # getter

## [1] 6.6

private_circle$size <- 7.7  # setter 
private_circle

## Circle of size 7.7

triangle$size

## [1] 8.2

triangle$expand(2)
triangle

## Regular polygon with 3 sides of size 16.4

We modified the original object

As seen from Java, Python, etc. …

• Finally, an Object Class that I understand!
• I understand public, private, self$
• I should use only R6!

… and that is a problem.

R users expect copy-on-change and may be confused by references.

Example from the package openxlsx (which uses Reference Classes)

workbook <- createWorkbook()
addWorksheet(workbook, "Sheet 1")

• Does not follow the pattern workbook$addWorksheet()
• Internally, addWorksheet() calls workbook$addWorksheet()
• So, did you or did you not add a worksheet to workbook?

names(workbook)   # calls names.Workbook()
## [1] "Sheet 1"

Martin Morgan (Bioconductor Project Lead), in reply to a
“I’m a C++/Python developer” point of view:

“R’s copy-on-change semantics leads me to expect that

b = a
slt(a) = 2

leaves b unchanged, which S4 does (necessarily copying and thus with a time and memory performance cost)."

[…]

“You either need to change your expectations, or use reference classes (and change the expectations of your users).”

You are using Bioconductor (S4 based) or a similar environment:

• Use S4

You must have reference objects due to the nature of the data

• Use R6 and avoid Reference Classes
  
• Manage user expectations: provide documentation, examples, etc.

You do not need reference objects:

• Use S3, if you have an option between S3 or S4
  • Google’s R Style Guide advises against using S4
    
• Better: use packages and a little of S3, e.g. for print()
  • packages promote modularity and encapsulation

Experience is:

• knowing what to do
• knowing what not to do
• learning from making mistakes
• better, learning from other people’s mistakes

The R Class Objects are far from perfect. So, what really works in R?

What are some of the best practices in R?

warning: subjective views / experience follows

• Follow a style guide, the most concise is Hadley’s style guide
• Break complex lines into components and pick meaningful names
  • one step closer to self-documenting code

df2 <- df[grepl(
    '^[0-9]{5}$', df$zip_code), ]     # usually the pattern is more complex

# vs

zip5_pattern <- '^[0-9]{5}$'
zip5_mask <- grepl(zip5_pattern, sales$zip_code)   
sales_with_zip <- sales[zip5_mask, ]

• Brandon Rhodes: The Naming of Ducks (video and slides)
  • It’s about Python, but it applies to R as well

If you are learning R …

• You are going to see many examples using old R functions, such as subset(), plot(), etc.
• Instead use dplyr, ggplot2 and other packages from the tidyverse
  • they promote clear and modular code
• Make use of pipe symbol %>% from magrittr, available in dplyr

For a detailed example, have a look at Zev Ross:
A new data processing workflow for R: dplyr, magrittr, tidyr, ggplot2

I dislike retyping %>% at the end of the line when the workflow changes

.end <- identity   # identity(x) returns x; .end is hidden

mtcars %>%
    select(mpg, cyl) %>%
    head(3) %>%    # now all the dplyr lines end with %>%
    .end

##                mpg cyl
## Mazda RX4     21.0   6
## Mazda RX4 Wag 21.0   6
## Datsun 710    22.8   4

Git and GitHub work better with fewer line changes

• Start with the data and aesthetics, add geoms, then make it look nice
• Add color dimension (continuous or discrete)
  • use ColorBrewer color schemes from RColorBrewer and ggplot

mtcars %>%
    mutate(cyl = factor(cyl)) %>%        # pipe your data into ggplot
    ggplot(aes(x = wt, y = mpg, color = cyl)) + 
    geom_point(size = 2) +
    scale_colour_brewer(palette = 'Dark2')

Functions => Pure Functions => Functional Programming

• In Data Science, pure functions are transformations of data frame columns
• Thinking in Excel, a pure function is a function that takes a table and returns a new column containing modified data

Writing pure functions in R makes it easier to deploy them in other production environments:

• Easier to migrate code to Python and Scala
• MS SQL Server 2016 allows R code in stored procedures
• MapReduce is based on functions (map and reduce)
• Spark is written in Scala, which has functional programming features