[Rd] assignInNamespace and new bindings

[Thomas Friedrichsmeier]

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?

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20110601/553724cf/attachment.bin>