Re: [R] Putting an object in to a function that calls the current function

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: Thu 05 Jan 2006 - 05:24:00 EST

On 1/4/2006 11:22 AM, Ales Ziberna wrote: > I do not belive this would work in my case, since as I said, the function is > called by several different functions.

This may not be welcome advice, but I don't think that is a great idea either. Conventionally using the same name for the same purpose in different functions is generally a good idea, but writing functions that depend on things being named identically is risky. You may find that in 2 years when you are editing this code that you change the name, but miss one of the locations: then you may get a very obscure bug. Or you may be reading through your function and forget that s() changes the value of a variable, so you won't understand what is going on in your code.

High level source code is meant equally for humans to read as it is for the interpreter to act on, so you should write it clearly.

I don't know the context of your problem, but I'd think a better approach would be to have your s() function return the variable a as part of its return value (so the several different functions could store it where they liked), or to define a in an environment where it is accessible from all the functions that need to use it including s(), and do something like the lexical scoping solution below.

Duncan Murdoch

> 
> Ales Ziberna 
> 
> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca] 
> Sent: Wednesday, January 04, 2006 5:05 PM
> To: Ales Ziberna
> Cc: 'R-help'
> Subject: Re: [R] Putting an object in to a function that calls the current
> function
> 
> On 1/4/2006 10:32 AM, Ales Ziberna wrote:

>> Thank you both (Duncan Murdoch and Gabor Grotehendieck) for your answers.
>> Both work and my problem is solved.
>>
>> I do aggree with Duncan Murdoch that usually messing with the
>> environment of your caller is a bad idea. The reason why I still want
>> to do it in this case is that I exactly know which functions are
>> calling (the function is NEVER called directly) it and it was in this
>> case easier to use this than to modify each of the fuctions that are
> calling it.
> 
> Using R's lexical scope may lead to a cleaner solution.  That is, you define
> the functions within the one that calls them; then a <<- "ok" 
> would do what you want (provided "a" existed in the enclosure at the time).
> 
> For example,
> 
> f <- function() {
> 	a <- "init"
> 	s <- function() {
> 		a <<- "ok"
>          }
> 	s()
> 	print(a)
> }
> 
> Duncan Murdoch
> 

>>
>> Thanks again!
>> Ales Ziberna
>>
>> -----Original Message-----
>> From: Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
>> Sent: Wednesday, January 04, 2006 3:26 PM
>> To: Ales Ziberna
>> Cc: R-help
>> Subject: Re: [R] Putting an object in to a function that calls the
>> current function
>>
>> On 1/4/2006 9:14 AM, Ales Ziberna wrote:
>>> Hello!
>>> 
>>> I would like to put an object in to a function that calls the current 
>>> function.
>>> 
>>> I thought the answer will be clear to me after reading the help files:
>>> ?assign
>>> ?sys.parent
>>> 
>>> However it is not.
>>> Here is an example I thought should work, however it dose not exactly:
>>> 
>>> f<-function(){s();print(a)}
>>> s<-function()assign(x="a",value="ok",pos=sys.parent())
>>> f() #I want to get "ok"
>>> a #I do not want "a" in global enviorment, so here I should get
>>> #Error: Object "a" not found
>>> ff<-function()f() #here I also want to get "ok" - it should not 
>>> matter if the parent fuction has any parents
>>> 
>>> Thank you in advance for suggestions!

>>
>> That's not a good idea. Why would you want to do something like that?
>>
>> That out of the way, here's a function that does it:
>>
>> f<-function(){s();print(a)}
>> s<-function()assign(x="a",value="ok",env=parent.frame())
>>
>> The difference between pos=sys.parent() and env=parent.frame() is that
>> the pos is interpreted as a position in the search list (see ?assign),
>> while
>> parent.frame() gives you the environment from the stack, equivalent to
>> sys.frame(sys.parent()).
>>
>> In R you're almost certainly better off working directly with
>> environments, rather than going through integer indexing the way you
>> (used to?) have to do in S-PLUS.
>>
>> Did I mention that messing with the environment of your caller is a
>> bad idea? It's not yours, don't touch it.
>>
>> Duncan Murdoch
> 
> ______________________________________________
> R-help@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html

______________________________________________
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Thu Jan 05 07:09:37 2006

This archive was generated by hypermail 2.1.8 : Thu 05 Jan 2006 - 11:01:00 EST