From therneau at mayo.edu  Fri Nov 25 18:12:29 2011
From: therneau at mayo.edu (Terry Therneau)
Date: Fri, 25 Nov 2011 11:12:29 -0600
Subject: [Rd] How to deal with package conflicts
In-Reply-To: <4ECFB773.2060106@yorku.ca>
References: <mailman.21.1322218808.15358.r-devel@r-project.org>
	<1322230252.5806.15.camel@nemo>  <4ECFB773.2060106@yorku.ca>
Message-ID: <1322241149.5806.120.camel@nemo>

 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.

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
changed.

Terry T.



[Rd] How to deal with package conflicts
Terry Therneau