[Rd] How to deal with package conflicts
murdoch.duncan at gmail.com
Fri Nov 25 19:37:18 CET 2011
On 25/11/2011 12:12 PM, Terry Therneau wrote:
> I like the idea of making the functions local, and will persue it.
> This issue has bothered me for a long time -- I had real misgivings when
> I introduced "cluster" to the package, but did not at that time see any
> way other than making it global.
> I might make this change soon in the ridge function, since it's a good
> test case -- less likely to cause downstream troubles.
> Here is another possible approach:
> Inside coxph, just before calling eval with the formula, create a new
> environment "tempenv" which consists of my handful of special functions
> (ridge, frailty, cluster, pspline) who have meaning only inside a coxph
> call, with a parent environment of the tempenv being the current
> environment of the formula. Then set the environment of the formula to
> tempenv, then eval. Would this work?
> Two small further questions:
> 1. Any special rules for the documentation? We need a page for
> "cluster", but want to mark it almost like a method in the sense of
> applying only in a one context.
I would list those special functions as aliases of the coxph topic, and
document them there.
> 2. Does one scheme or another work best for downstream functions like
> predict or model.matrix? Duncan's idea of direct modification might
> have an advantage (?) in that the terms object would be permanently
As long as you attach your new temporary environment to copies of the
formula that you pass elsewhere, it should mostly work. It may confuse
someone who did ls(environment(formula)) (because they'd only see your
functions, not the user's), but I don't think that's a very common thing
to want to do.
More information about the R-devel