[Rd] assignInNamespace and new bindings

[luke-tierney at uiowa.edu]

On Wed, 1 Jun 2011, Thomas Friedrichsmeier wrote:

> Hi,
>
> On Tuesday 31 May 2011, luke-tierney at uiowa.edu wrote:
>> Yes you should. Changing things in other people's packages is not a
>> safe thing to do.
>
> sorry to insist, but I was hoping for a slightly more specific pointer. I'll
> try asking it another way:
>
> Suppose I was using assignInNamespace() entirely bona fide, i.e. to develop and
> test patches with the intent to offer them to the package maintainer(s) for
> inclusion. What sort of gotchas should I be looking out for, specifically with
> respect to the compiler? Also, if the package that I'm trying to improve is a
> base package?

At the moment the main issue is that the assignment may not have any
effect on compiled code because the compiled code accesses the
finctionality known to be provided by these funcions in some more
direct way.  Examples are BUILTIN functions, which are called directly
through the internal table, and some functions that are simple
wrappers around .Internal calls where the compiled code in effect goes
directly to the .Internal call.  At the moment this applies only to
some functions in base packages but may in the future extend to other
packages.

Best,

luke

>
> Regards
> Thomas
>
> P.S.: Just to let you know, why I do not feel too much ashamed or scared of
> changing things in other people's packages, here's (slighlty simplified) the
> pattern that I'm following:
>
> backup <- original
> replacement <- function() {
>      call.my.hook()
>      eval(body(backup))
> }
> formals(replacement) <- formals(backup)
> environment(replacement) <- environment(backup)
> assignInNamespace(...)
>
> I know that leaves subtle differences beyond anything the compiler may be
> doing, such as in the sys.calls(). I am also pretty certain that these subtle
> differences are completely irrelevant *in those functions that I modify* this
> way. And I have a bunch of automated tests to make me sleep better, too.
>
> Ok, and for a select few functions, my replacements are more "radical", such
> as for utils::savehistory(). But then, that is essentially non-functional in
> my use-case in its original incarnation, in the first place, so I'm not really
> scared of making things worse, there, either.
>

-- 
Luke Tierney
Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu