5

I'm just getting my feet wet in R and was surprised to see that a function doesn't modify an object, at least it seems that's the default. For example, I wrote a function just to stick an asterisk on one label in a table; it works inside the function but the table itself is not changed. (I'm coming mainly from Ruby)

So, what is the normal, accepted way to use functions to change objects in R? How would I add an asterisk to the table title?

  • Replace the whole object: myTable = title.asterisk(myTable)

  • Use a work-around to call by reference (as described, for example, in Call by reference in R by TszKin Julian?

  • Use some structure other than a function? An object method?

Mike Blyth
  • 4,158
  • 4
  • 30
  • 41
  • 1
    What object type is `myTable`? – Roman Luštrik Mar 19 '13 at 11:16
  • To elaborate: is "table title" an attribute of your `myTable` object, and if so what function do you use to set the attribute in the first place? – Carl Witthoft Mar 19 '13 at 11:23
  • Well, I'm more interested in the generic answer, though the actual table I'm modifying at the moment is a CrossTable from the descr package. The labels are set when the object is created, and I'm saying "attr(tbl$t,'dimnames')[[2]][level.index] = paste0(level.val, marker)" to add an asterisk to one of them. – Mike Blyth Mar 19 '13 at 12:09
  • 1
    @MikeBlyth I've written up a generic answer for you that you may find informative, even if it may not fully solve your problem. I hope it helps with your transition into R. – Dinre Mar 19 '13 at 12:14

3 Answers3

27

The reason you're having trouble is the fact that you are passing the object into the local namespace of the function. This is one of the great / terrible things about R: it allows implicit variable declarations and then implements supercedence as the namespaces become deeper.

This is affecting you because a function creates a new namespace within the current namespace. The object 'myTable' was, I assume, originally created in the global namespace, but when it is passed into the function 'title.asterisk' a new function-local namespace now has an object with the same properties. This works like so:

title.asterisk <- function(myTable){ do some stuff to 'myTable' }

In this case, the function 'title.asterisk' does not make any changes to the global object 'myTable'. Instead, a local object is created with the same name, so the local object supercedes the global object. If we call the function title.asterisk(myTable) in this way, the function makes changes only to the local variable.

There are two direct ways to modify the global object (and many indirect ways).

Option 1: The first, as you mention, is to have the function return the object and overwrite the global object, like so:

title.asterisk <- function(myTable){
    do some stuff to 'myTable'
    return(myTable)
}
myTable <- title.asterisk(myTable)

This is okay, but you are still making your code a little difficult to understand, since there are really two different 'myTable' objects, one global and one local to the function. A lot of coders clear this up by adding a period '.' in front of variable arguments, like so:

title.asterisk <- function(.myTable){
    do some stuff to '.myTable'
    return(.myTable)
}
myTable <- title.asterisk(myTable)

Okay, now we have a visual cue that the two variables are different. This is good, because we don't want to rely on invisible things like namespace supercedence when we're trying to debug our code later. It just makes things harder than they have to be.

Option 2: You could just modify the object from within the function. This is the better option when you want to do destructive edits to an object and don't want memory inflation. If you are doing destructive edits, you don't need to save an original copy. Also, if your object is suitably large, you don't want to be copying it when you don't have to. To make edits to a global namespace object, simply don't pass it into or declare it from within the function.

title.asterisk <- function(){ do some stuff to 'myTable' }

Now we are making direct edits to the object 'myTable' from within the function. The fact that we aren't passing the object makes our function look to higher levels of namespace to try and resolve the variable name. Lo, and behold, it finds a 'myTable' object higher up! The code in the function makes the changes to the object.

A note to consider: I hate debugging. I mean I really hate debugging. This means a few things for me in R:

  • I wrap almost everything in a function. As I write my code, as soon as I get a piece working, I wrap it in a function and set it aside. I make heavy use of the '.' prefix for all my function arguments and use no prefix for anything that is native to the namespace it exists in.
  • I try not to modify global objects from within functions. I don't like where this leads. If an object needs to be modified, I modify it from within the function that declared it. This often means I have layers of functions calling functions, but it makes my work both modular and easy to understand.
  • I comment all of my code, explaining what each line or block is intended to do. It may seem a bit unrelated, but I find that these three things go together for me. Once you start wrapping coding in functions, you will find yourself wanting to reuse more of your old code. That's where good commenting comes in. For me, it's a necessary piece.
Dinre
  • 4,196
  • 17
  • 26
  • 2
    Wise comments at the end of the post -- definitely worth a +1. – Dirk Eddelbuettel Mar 19 '13 at 13:22
  • Thanks for the great explanation. Being heavily indoctrinated by Ruby, I rarely even think about the fact that a global variable could be modified in a function, and shudder when I do think of it. But different languages demand different techniques, so it's good to keep this up my sleeve for R. – Mike Blyth Mar 19 '13 at 13:28
10

The two paradigms are replacing the whole object, as you indicate, or writing 'replacement' functions such as

`updt<-` <- function(x, ..., value) {
    ## x is the object to be manipulated, value the object to be assigned
    x$lbl <- paste0(x$lbl, value)
    x
}

with

> d <- data.frame(x=1:5, lbl=letters[1:5])
> d
  x lbl
1 1   a
2 2   b
3 3   c
> updt(d) <- "*"
> d
  x lbl
1 1  a*
2 2  b*
3 3  c*

This is the behavior of, for instance, $<- -- in-place update the element accessed by $. Here is a related question. One could think of replacement functions as syntactic sugar for

updt1 <- function(x, ..., value) {
    x$lbl <- paste0(x$lbl, value)
    x
}
d <- updt1(d, value="*")

but the label 'syntactic sugar' doesn't really do justice, in my mind, to the central paradigm that is involved. It is enabling convenient in-place updates, which is different from the copy-on-change illusion that R usually maintains, and it is really the 'R' way of updating objects (rather than using ?ReferenceClasses, for instance, which have more of the feel of other languages but will surprise R users expecting copy-on-change semantics).

Community
  • 1
  • 1
Martin Morgan
  • 45,935
  • 7
  • 84
  • 112
  • Thanks for the quick answer. If I understand correctly from the related question you linked to, "What are Replacement Functions in R?", they are just syntactic sugar for x <- f(x). Is that right? – Mike Blyth Mar 19 '13 at 12:00
2

For anybody in the future looking for a simple way (do not know if it is the more appropriate one) to get this solved:

Inside the function create the object to temporally save the modified version of the one you want to change. Use deparse(substitute()) to get the name of the variable that has been passed to the function argument and then use assign() to overwrite your object. You will need to use envir = parent.frame() inside assign() to let your object be defined in the environment outside the function.

(MyTable <- 1:10)

[1] 1 2 3 4 5 6 7 8 9 10

title.asterisk <- function(table) {
  tmp.table <- paste0(table, "*")
  name      <- deparse(substitute(table))
  assign(name, tmp.table, envir = parent.frame())
}

(title.asterisk(MyTable))

[1] "1*" "2*" "3*" "4*" "5*" "6*" "7*" "8*" "9*" "10*"

Using parentheses when defining an object is a little more efficient (and to me, better looking) than defining then printing.

Cris
  • 325
  • 1
  • 5
  • 20
  • I've heard that we should never use `assign`, but this is so cool that I had to make a snippet (https://github.com/learn-bioinformatics/crazy_R) – Christopher Bottoms Apr 15 '22 at 15:10
  • I understand the part of not changing user’s workspace without asking before, but could you please tell if there is another reason why should we never use assign? – Cris Apr 17 '22 at 01:41
  • 1
    My first thought is that it goes against the R philosophy for functions not to modify arguments as a "side-effect", so it could easily end up as a surprise and maintenance headache for someone, but see also https://stackoverflow.com/questions/17559390/why-is-using-assign-bad for other reasons. And also see additional ideas and discussion (especially in the comments) here: https://stackoverflow.com/questions/54064394/when-is-rs-assign-function-appropriate). – Christopher Bottoms Apr 18 '22 at 15:06