[Rd] How to deal with package conflicts

[Duncan Murdoch]

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