[R] Accessing objects manipulated in a function

[Bert Gunter]

"... wonton (as in "users will change my variables this way") use of
that operator will inevitably lead to surprises and puzzlement later.
"

Is this related to the myriad of choices in a Chinese menu? ;-)

(The spelling is "wanton" -- ah the joys of English!)


Cheers,
Bert


Bert Gunter

"The trouble with having an open mind is that people keep coming along
and sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Sat, May 14, 2016 at 9:45 AM, Jeff Newmiller
<jdnewmil at dcn.davis.ca.us> wrote:
> I think you have boxed yourself into a corner, much like someone painting
> the floor and failing to work their way toward an exit.
>
> The whole premise that you will call "unknown code" that does "unknown
> things" that change the global environment is a maintenance disaster. Give
> up on at least one of these requirements.
>
> Think of the "lm" function. It returns a list of related results, augmented
> with a "class" attribute so that methods like "print.lm" and "summary.lm"
> will work. The actions performed need not be reviewed in detail if the user
> knows what to do with the returned object. The "class" attribute is a bit of
> syntactic sugar, but the concept of putting your results into a list that
> the caller doesn't have to mix items in with their own is critical.
>
> Using <<- has to be handled in a very controlled manner... wonton (as in
> "users will change my variables this way") use of that operator will
> inevitably lead to surprises and puzzlement later.
>
> I also happen to think that standardizing on calling "source" inside
> functions is a big mistake... the functions defined by the user should be
> setup and handed off to your "master architecture" code as parameters or
> elements within lists that are parameters.
>
> On Sat, 14 May 2016, Fisher Dennis wrote:
>
>> R 3.2.4
>> OS X and Windows
>>
>> Colleagues,
>>
>> I distribute some code to co-workers and I am trying to simplify their
>> task.  The issue is as follows:
>>
>> 1.  The code automates an extensive set of processes.  Many of the steps
>> are standardized.  However, some of the steps may require that users write
>> snippets of code, stored in R scripts.
>>
>> 2.  If users write their own code, it might appear in files named
>> UserCode1.R, UserCode2.R, etc..  The master code checks for the existence of
>> this code, then executes
>>         source(?/path/to/UserCode1.R?)
>> This can occur at many different points in the master code (each time
>> sourcing a different file). In addition to the command above, there are a
>> variety of other commands testing whether the file exists and whether it
>> contains certain commands that I don?t allow the user to execute.
>> In order to simplify the code, these commands are embedded in a function
>> (which I will call MODIFYCODE for the moment).
>>
>> 3.  Assume that an object within the master code is named TEMP.  The user
>> might add a column to TEMP.  Since this occurs within a function, there are
>> two ways to get this modification back to the original environment:
>>         a.  within the function:        TEMP    <<- TEMP
>>         b.  use the return value from the function:
>>                 TEMP    <-   MODIFYCODE()
>>
>> 4.  There are disadvantages to each of these:
>>         a.  The user needs to know that the ?<<-? command must be invoked.
>> If they don?t do so, the changes within the function are not available in
>> the master environment
>>         b.  I don?t know what code will be written by the user, i.e., they
>> might manipulate TEMP or they might create a new object or something else.
>> So, I don?t know a priori what to return.
>>
>> So, my question is: is there some way to manipulate environments such that
>> the changes within the function are AUTOMATICALLY transferred to the
>> environment outside the function?
>>
>> Dennis
>>
>> Dennis Fisher MD
>> P < (The "P Less Than" Company)
>> Phone / Fax: 1-866-PLessThan (1-866-753-7784)
>> www.PLessThan.com <http://www.plessthan.com/>
>>
>>
>>
>>
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
>
> ---------------------------------------------------------------------------
> Jeff Newmiller                        The     .....       .....  Go Live...
> DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
>                                       Live:   OO#.. Dead: OO#..  Playing
> Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
> /Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
>
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.