Skip to content

Global variables

6 messages · Duncan Murdoch, Gabor Grothendieck, Sebastien Bihorel +1 more

#
On 06/01/2011 4:45 PM, Sebastien Bihorel wrote:
Yes, but you probably shouldn't.  You would do it by setting the 
environment of the function to something that doesn't have the global 
environment as a parent, or grandparent, etc.  The only common examples 
of that are baseenv() and emptyenv().  For example,

x <- 1
f <- function() print(x)

Then f() will work, and print the 1.  But if I do

environment(f) <- baseenv()

then it won't work:

 > f()
Error in print(x) : object 'x' not found

The problem with doing this is that it is not the way users expect 
functions to work, and it will probably have weird side effects.  It is 
not the way things work in packages (even packages with namespaces will 
eventually search the global environment, the namespace just comes 
first).  There's no simple way to do it and yet get access to functions 
in other packages besides base without explicitly specifying them (e.g. 
you'd need to use stats::lm(), not just lm(), etc.)

Duncan Murdoch
#
On Thu, Jan 6, 2011 at 4:59 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
A variation of this would be:

environment(f) <- as.environment(2)

which would skip over the global environment, .GlobEnv, but would
still search the loaded packages.  In the example above x would not be
found but it still could find lm, etc.
3 days later
#
Hi Sebastian,

You might also find the proto package useful as a way of restricting
the scope of variables. It provides a more intuitive (at least to me)
way of packaging variables and functions up into environments that can
be related in a hierarchy.

Michael

On 10 January 2011 23:48, Sebastien Bihorel
<Sebastien.Bihorel at cognigencorp.com> wrote:
#
Thanks,

I will have a look at it.

Sebastien
Michael Bedward wrote: