Isolating functions

Something for the global namespace:

global = 42

And a function accessing it:

fun = function (globl) {
    message('Called as: ', deparse(match.call()))
    global * 2 # Note the typo
}

Let’s call it:

fun(1)

Called as: fun(globl = 1)

[1] 84

Ouch, wrong object accessed!

No worries, set the function environment to something that doesn’t inherit the globalenv():

environment(fun) = emptyenv()
try(fun(1))

Error in fun(1) : could not find function "{"

Shoot! The problem: virtually everything — including `{` and `*` — is defined inside some package (such as base). emptyenv() by default does not inherit any objects; it is empty. We can’t even qualify object access via the pkg::obj syntax, because `::` is also defined in baseenv().

One solution would be to use baseenv() instead of emptyenv():

fun2 = function () {
    # Rather than generating an error, inspect the parent environment.
    parent = parent.env(environment())
    env_name = environmentName(parent)
    env_name = if (env_name == '')
        'Unnamed parent environment'
    else
        paste('Parent environment', dQuote(env_name))
    env_size = length(ls(envir = parent))
    sprintf('%s has %g objects', env_name, env_size)
}
    
environment(fun2) = baseenv()
fun2()

[1] "Parent environment “base” has 1215 objects"

That’s better. However, using baseenv() isn’t actually a good idea either because base is, well, base. And we don’t really have any business mucking around in it. Instead, we should create our own environment:

myenv = new.env(parent = baseenv())
environment(fun2) = myenv
fun2()

[1] "Unnamed parent environment has 0 objects"

There. This is what we want. We can make two more adjustments:

1. If our environment inherits from baseenv(), we can only use objects defined there, and not others, defined in attached packages. This may or may not be what we want (we can still access other packages by explicitly qualifying them: pkg::obj).

   Alternatively, we can use a different parent environment, e.g. the parent environment of the global environment; that way, our function will have access to all attached packages, but not to the global environment itself.

2. When defining a bunch of functions this way, we can use local or eval to define them directly inside our cleanroom environment.

Regarding the first point, we can simply write:

myenv = new.env(parent = parent.env(globalenv()))
environment(fun2) = myenv
fun2()

[1] "Unnamed parent environment has 0 objects"

The difference: we now have access to attached packages. E.g.:

fun3 = function () {
    plot(speed ~ dist, cars)
}
environment(fun3) = myenv
fun3()

Here plot comes from package:graphics, and cars comes from package:datasets.

Regarding the second point, we can either use local:

local({
    fun4 = function () 'hello'
    fun5 = function (x, y) x + y
    # … etc.
}, envir = myenv)
myenv$fun4()

[1] "hello"

… or we can put the functions into a separate file and use source with appropriate parameters:

source(file = 'mymodule.r', local = myenv)

But once we reach that point, we might as well use the ‹modules› package from GH:klmr/modules:

mod = modules::import('mymodule')
mod$fun4()