[Rd] How to deal with package conflicts

Michael Friendly friendly at yorku.ca
Fri Nov 25 16:42:43 CET 2011

On 11/25/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 provided one suggestion:  make ridge() an S3 generic, and rename 
to ridge.coxph(), but this won't work, since you use ridge() inside 
coxph() and
survreg() to add a penalty term in the model formula.
Another idea might be simply to not export ridge(), but I have the 
feeling this will break
your R CMD checks.

Alternatively, my particular problem (wanting to use car::vif in my 
package documentation) would
be solved if John Fox considered making making survival a Suggests: 
package rather than a
Depends: one.  This might work, since survival is only referenced in car 
by providing Anova()
methods for coxph models.

I think all of this raises a general issue of unintended consequences of 
"package bloat," where
(a) Depends: packages are forced to load by require()/library(), whether 
they are really needed or not;
(b) There is nothing like require(car, depends=FALSE) to circumvent this;
(c) Once a require()'d package is loaded, it cannot be unloaded;
(d) AFAIK, there is no way for a package author to override the masking 
of functions or data
provided by other other packages, except by using mypackage::myfun() calls.

To me this seems to be a flaw in the namespace mechanism.


Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University      Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele Street    Web:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA

More information about the R-devel mailing list