[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
ridge()
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.
best,
-Michael
--
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