Philippe J. S. De Brouwer - The Big R-Book

Why does the second approach fail? Would you expect it to work?

It appears that while the object my_accexist, it is not possible to insert it in the definition of a new object – even while this inherits from the first. This makes sense, because the object “account” is not an attribute of the object “current account,” but its attributes become directly attributes of current account.

The object my_curr_accis now ready to be used. For example, we can change the balance.

my_curr_acc @balance <-500

Now, we will create an investment account. At this point, it becomes crucial to see that the object “custodian bank” is not a parent class, but rather an attribute. This means that before we can create an investment account, we need to define at least one custodian.

my_inv_acc <- new(“InvAcc”, custodian = my_cust_bank, holder=“Philippe”, branch=“DUB01”, opening_date = as.Date(“2019-02-21”)) # note that the first slot is another S4 object:my_inv_acc ## An object of class “InvAcc” ## Slot “custodian”: ## An object of class “Bnk” ## Slot “name”: ## [1] “HSBC” ## ## Slot “phone”: ## [1] “123123123” ## ## ## Slot “holder”: ## [1] “Philippe” ## ## Slot “branch”: ## [1] “DUB01” ## ## Slot “opening_date”: ## [1] “2019-02-21”

If you look careful at the code fragment above this question, you will notice that it is possible to provide an object my_cust_bankas attribute to the object my_inv_acc. This situation is similar to the code just above previous question, but unlike in the creation of also_an_account, now it works. Why is this?

To understand what happened here, we need to dig a little deeper.

my_inv_acc @custodian # our custodian bank is HSBC## An object of class “Bnk” ## Slot “name”: ## [1] “HSBC” ## ## Slot “phone”: ## [1] “123123123” my_inv_acc @custodian @name # note the cascade of @ signs## [1] “HSBC” my_inv_acc @custodian @name <-“DB” # change it to DBmy_inv_acc @custodian @name # yes, it is changed## [1] “DB” my_cust_bank @name # but our original bank isn't## [1] “HSBC” my_cust_bank @name <-“HSBC Custody” # try something differentmy_inv_acc @custodian @name # did not affect the account## [1] “DB” my_inv_acc @custodian @name <-my_cust_bank @name # change back

The function getSlots()will return a description of all the slots of a class:

getSlots(“Acc”) ## holder branch opening_date ## “character” “character” “Date” getSlots()

While S3 provides no mechanism to check if all attributes are of the right type, creating an S4 object with the function new()will check if the slots are of the correct type. For example, if we try to create an account while providing a string for the balance (while a number is expected), then R will not create the new object and inform us of the mistake.

# Note the mistake in the following code:my_curr_acc <- new(“CurrAcc”, holder = “Philippe”, interest_rate = 0.01, balance=“0”, # Here is the mistake!branch = “LDN12”, opening_date= as.Date(“2018-12-01”)) ## Error in validObject(.Object): invalid class “CurrAcc” object: invalid object for slot “balance” in class “CurrAcc”: got class “character”, should be or extend class “numeric”

If you omit a slot, R coerces that slot to the default value.

x_account <- new(“CurrAcc”, holder = “Philippe”, interest_rate = 0.01, #no balance providedbranch = “LDN12”, opening_date= as.Date(“2018-12-01”)) x_account @balance # show what R did with it## numeric(0)

Did you notice that R is silent about the missing balance? This is something to be careful with. If you forget that a default value has been assigned then this might lead to confusing mistakes.

An empty value for balance is not very useful and it can even lead to errors. Therefore, it is possible to assign default values with the function prototypewhen creating the class definition.

prototype()

setClass(“CurrAcc”, representation(interest_rate = “numeric”, balance = “numeric”), contains = “Acc”, prototype(holder = NA_character_, interst_rate = NA_real_, balance = 0)) x_account <- new(“CurrAcc”, # no holder # no interest rate # no balancebranch = “LDN12”, opening_date= as.Date(“2018-12-01”)) x_account # show what R did:## An object of class “CurrAcc” ## Slot “interest_rate”: ## numeric(0) ## ## Slot “balance”: ## [1] 0 ## ## Slot “holder”: ## [1] NA ## ## Slot “branch”: ## [1] “LDN12” ## ## Slot “opening_date”: ## [1] “2018-12-01”

Most programming languages implement an OO system where class definitions are created when the code is compiled and instances of classes are created at runtime. During runtime, it is not possible to change the class definitions.

However, R is an interpreted language that is interactive and functional. The consequence is that it is possible to change class definitions at runtime (“while working in the R-terminal”). So it is possible to call setClass()again with the same object name, and R will assume that you want to change the previously defined class definition and silently override it. This can lead, for example, to the situation where different objects pretend to be of the same class, while they are not.

To make sure that a previous class definition cannot be changed add sealed = TRUEto the call to setClass()

It is common practice to use “UpperCamelCase” for S4 class names. a Using a convention is always a good idea, using one that many other people use is even better. This convention avoids any confusion with the dispatcher functions that use the dot as separator.