Re: [Rd] assignInNamespace and new bindings

From: <luke-tierney_at_uiowa.edu>
Date: Wed, 01 Jun 2011 13:44:48 -0500

On Wed, 1 Jun 2011, Thomas Friedrichsmeier wrote:

> Hi,
>
> On Tuesday 31 May 2011, luke-tierney@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

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Wed 01 Jun 2011 - 18:47:10 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 01 Jun 2011 - 21:00:14 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive