Just one correction. The line environment(fun.global) <- environment()
line below should be deleted. It was needed in a prior example but in this one
we use parent.frame()$setVar(4) in the call so that line is not needed in main.
On Fri, Aug 21, 2009 at 7:09 AM, Gabor
Grothendieck wrote:
> Yet ano
On 8/21/2009 6:33 AM, Renaud Gaujoux wrote:
Thanks Duncan, I agree that touching the environments is risky and not
robust. I rather go for another solution.
But the function solution still require to pass an extra object to the
user's function. I'd like the user to simply be able to call functio
I think you need to consider particular scenarios in which this is used
and the characteristics of the user since there are going to be tradeoffs
in the design.
It may be that by examining typical usage cases that you find that
the fun.global2 situation (i.e. fun.global calls fun.global2 calls set
And to make things a bit more difficult: I also use the multicore package.
So I guess that naively modifying setVar in my package namespace would
not be appropriate as each process needs to define its own setVar
function. Unless setVar is implemented so that it knows which process is
calling it
Certainly its possible to dynamically write to the package's namespace.
For example, lattice does that. It stores various lattice options there.
Injecting setVar is not really more conservative though. Consider that
when you modify the environment of a function in main:
environment(fun.global)
Ah! It looks interesting and seems more conservative than changing the
actual environment. I could do the restore within an on.exit to deal
with the error eventuality.
Do you think could define a dummy setVar function in my package
namespace, and change its behaviour on runtime?
This way, as s
Another possibility is that you could inject setVar into
fun.global's environment.
First save any existing setVar in fun.global's environment to tmp
and then assign our own setVar there. We then run fun.global()
and reverse the changes we made in fun.global's environment
setting everything back t
Thanks Duncan, I agree that touching the environments is risky and not
robust. I rather go for another solution.
But the function solution still require to pass an extra object to the
user's function. I'd like the user to simply be able to call function
setVar as if it was a standard R function
On 8/20/2009 4:27 AM, Renaud Gaujoux wrote:
Hi,
in my project I want the user to be able to write hook functions that
are in turn called in my main code. I'd like the user's hooks to be able
to call some function that set a variable outside their running
environment.
The trick is that this v
Indeed.
So is there no way to do that without passing an object as parameter,
which acts as a 'global local' workspace?
Isn't there a way to do say: "run this function and subsequent calls
within this environment"?
Gabor Grothendieck wrote:
A function finds its free variables in its environme
A function finds its free variables in its environment. Changing
the environment of one function does not change the environment of
other functions; however, if instead of messing with environments you
use the proto solution already posted then that would handle this situation
by passing the objec
Hi Gabor,
thanks.
Indeed I reckon implementing it using an object would be better, but I
wanted to keep it as simple as possible for the end user, by hiding the
object mechanism. The user would not have to define its function with an
extra parameter, maybe obscure to him.
My problem now is t
I am not sure what the purpose of workspace is so I
have eliminated it in the following. We just use the
environment within main and when main exits all its
variables go too so that seems sufficient.
fun.global <- function() { message('fun.global'); setVar(5) }
main <- function() {
l.var
Hi,
in my project I want the user to be able to write hook functions that
are in turn called in my main code. I'd like the user's hooks to be able
to call some function that set a variable outside their running
environment. The trick is that this variable is not global, but defined
on runtime
14 matches
Mail list logo
