Hi Michael, I'll look into moving survival to suggests (this weekend, if I have time), but that doesn't address the more general issue.
Best, John > -----Original Message----- > From: Michael Friendly [mailto:frien...@yorku.ca] > Sent: November-25-11 10:43 AM > To: Terry Therneau > Cc: r-devel@r-project.org; John Fox; Duncan Murdoch > Subject: Re: [Rd] How to deal with package conflicts > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
