Set the environment of a function placed outside the .GlobalEnv

问题

I want to attach functions from a custom environment to the global environment, while masking possible internal functions.

Specifically, say that f() uses an internal function g(), then:

f() should not be visible in .GlobalEnv with ls(all=TRUE).
f() should be usable from .GlobalEnv.
f() internal function g() should not be visible and not usable from .GlobalEnv.

First let us create environments and functions as follows:

assign('ep', value=new.env(parent=.BaseNamespaceEnv), envir=.BaseNamespaceEnv)
assign('e', value=new.env(parent=ep), envir=ep)
assign('g', value=function() print('hello'), envir=ep)
assign('f', value=function() g(), envir=ep$e)

ls(.GlobalEnv)
## character(0)

Should I run now:

ep$e$f()
## Error in ep$e$f() (from #1) : could not find function "g"

In fact, the calling environment of f is:

environment(get('f', envir=ep$e))
## <environment: R_GlobalEnv>

where g is not present.

Trying to change f's environment gives an error:

environment(get('f', envir=ep$e))=ep
## Error in environment(get("f", envir = ep$e)) = ep : 
##   target of assignment expands to non-language object

Apparently it works with:

environment(ep$e$f)=ep
attach(ep$e)

Now, as desired, only f() is usable from .GlobalEnv, g() is not.

f()
[1] "hello"
g()
## Error: could not find function "g" (intended behaviour)

Also, neither f() nor g() are visible from .GlobalEnv, but unfortunately:

ls(.GlobalEnv)
## [1] "ep"

Setting the environment associated with f() to ep, places ep in .GlobalEnv.
Cluttering the Global environment was exactly what I was trying to avoid.
Can I reset the parent environment of f without making it visible from the Global one?

UPDATE
From your feedback, you suggest to build a package to get proper namespace services.
The package is not flexible. My helper functions are stored in a project subdir, say hlp, and sourced like source("hlp/util1.R").
In this way scripts can be easily mixed and updated on the fly on a project basis.

(Added new enumerated list on top)

UPDATE 2

An almost complete solution, which does not require external packages, is now here.

回答1:

Either packages or modules do exactly what you want. If you’re not happy with packages’ lack of flexibility, I suggest you give ‹modules› a shot: they elegantly solve your problem and allow you to treat arbitrary R source files as modules:

Just prefix the “hidden” functions with a dot (g → .g)¹. Write these definitions to a file foo.r, and load it via

foo = import('foo')
foo$f()

import_package('foo', attach = TRUE)
f()

This fulfils all the points in your enumeration. In particular, both pieces of code make f, but not .g, available to the caller. In addition, modules have numerous other advantages over using source.

On a more technical note, your code results in ep being inside the global environment because the assignment environment(ep$e$f)=ep creates a copy of ep inside your global environment. Once you’ve attached the environment, you can delete this object. However, the code still has issues (it’s more complex than necessary and, as Hong Ooi mentioned, you shouldn’t mess with the base namespace).

¹ Currently, this is how modules signal unexported objects. A future version of modules will allow another mechanism that doesn’t require adjusting the object’s name.

回答2:

First, you shouldn't be messing around with the base namespace. Cluttering up the base because you don't want to clutter up the global environment is just silly.*

Second, you can use local() as a poor-man's namespacing:

e <- local({
    g <- function() "hello"
    f <- function() g()
    environment()
})

e$f()
# [1] "hello"

* If what you have in mind is a method for storing package state, remember that (essentially) anything you put in the global environment will be placed in its own namespace when you package it up. So don't worry about cluttering things up.

来源：https://stackoverflow.com/questions/41133617/set-the-environment-of-a-function-placed-outside-the-globalenv

标签

module

scope