Hi Michael, As promised, I've moved survival to Suggests in the development version of the car package on R-Forge. AFAICS, this doesn't cause any problems (and should solve your problem).
I incidentally added Anova() and linearHypothesis() methods for svyglm objects, and placed the survey package under Suggests. Best, John > -----Original Message----- > From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- > project.org] On Behalf Of John Fox > Sent: November-25-11 11:47 AM > To: 'Michael Friendly' > Cc: 'Terry Therneau'; r-devel@r-project.org > Subject: Re: [Rd] How to deal with package conflicts > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel