From friendly at yorku.ca  Fri Nov 25 16:42:43 2011
From: friendly at yorku.ca (Michael Friendly)
Date: Fri, 25 Nov 2011 10:42:43 -0500
Subject: [Rd] How to deal with package conflicts
In-Reply-To: <1322230252.5806.15.camel@nemo>
References: <mailman.21.1322218808.15358.r-devel@r-project.org>
	<1322230252.5806.15.camel@nemo>
Message-ID: <4ECFB773.2060106@yorku.ca>

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



[Rd] How to deal with package conflicts
Michael Friendly