How to deal with package conflicts
On 25/11/2011 9:10 AM, Terry Therneau wrote:
The ridge() function was put into the survival package as a simple example of what a user could do with penalized functions. It's not a "serious" function, and I'd be open to any suggestions for change. Actually, for any L2 penalty + Cox model one is now better off using coxme as the maximization process is much better thought out there. I'd be happy to remove ridge from survival -- except that there are bound to be lots of folks using the function and any such changes (even good ones) to the survival package are fraught with peril. Duncan: this raises a larger point. I've often wished that I could have "namespace" like rules apply to formulas. Using survival again, when I implemented gam-like smooths I had to create "pspline" rather than use the more natural "s()" notation. In survival, it would be good to do this for ridge, cluster, pspline, and frailty; all of whom depend deeply on a coxph context. It would also solve a frailty() problem of long standing, that when used in survreg only a subset of the frailty options make sense; this is documented in the help file but catches users again and again.
I think the general idea in formulas is that it is up to the user to define the meaning of functions used in them. Normally the user has attached the package that is working on the formula, so the package author can provide useful things like s(), but if a user wanted to redefine s() to their own function, that should be possible. Formulas do have environments attached, so both variables and functions should be looked up there. This not perfectly applied, of course. It is generally up to the function interpreting the formula to define what "+" means, for example. You could also have the function treat s() and other functions specially, but this is likely to be a little risky. (I'm in the process of putting together a small package for displaying tables; it treats +, *, and a few other function-like things specially: Format, .Format, Heading and Justify. I chose capital letters for those to hopefully avoid conflicts with a user's own functions. Perhaps I should have used dots on all of them.) Duncan Murdoch
Terry Therneau On Fri, 2011-11-25 at 12:00 +0100, r-devel-request at r-project.org wrote:
> In my genridge package, I define a function ridge() for ridge > regression, creating objects of class 'ridge' > that I intend to enhance. > > In a documentation example, I want to use some functions from the
car
> package. However, that package > requires survival, which also includes a ridge() function, for coxph > models. So, once I require(car) > my ridge() function is masked, which means I have to use the awkward > form below in my .Rd files. > > ridgemod<- genridge::ridge(...) > > I tried to detach survival, but that doesn't work: >
> > detach("package:survival")
> Error: package ?survival? is required by ?car? so will not be
detached
>
> I don't see any solution to this, other than
> (a) renaming my ridge() to something else -- don't want to do this
> (b) use \dontrun{} for the examples that use car
>
> Or, is there some other way?
Not really. I'd say the renaming is the preferred way to go, but you might also be able to convince Terry Therneau (survival author) to make ridge() a generic, so your method is called for your objects, and his is called for others. Duncan Murdoch