Hi, On Tuesday 31 May 2011, [email protected] 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.
signature.asc
Description: This is a digitally signed message part.
______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
