From therneau at mayo.edu  Fri Nov 25 17:08:26 2011
From: therneau at mayo.edu (Terry Therneau)
Date: Fri, 25 Nov 2011 10:08:26 -0600
Subject: [Rd] How to deal with package conflicts
In-Reply-To: <4ECFB773.2060106@yorku.ca>
References: <mailman.21.1322218808.15358.r-devel@r-project.org>
	<1322230252.5806.15.camel@nemo>  <4ECFB773.2060106@yorku.ca>
Message-ID: <1322237306.5806.92.camel@nemo>


On Fri, 2011-11-25 at 10:42 -0500, Michael Friendly wrote:
> 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.
> 

The S3 generic idea won't work.  The argument inside ridge(x) is an
ordinary variable, and it's the argument inside that a generic uses for
dispatch.  I want to dispatch based on the context, which is what the
namespace mechanism does for a call to for instance coxpenal.fit, a non
exported survival function.  
  
I suspect that not exporting ridge would work for
	coxph(Surv(time, status) ~ ph.ecog + ridge(age), data=lung)
but not for
      myform <-Surv(time, status) ~ ph.ecog + ridge(age)
      coxph(myform, data=lung)

(I haven't test this)  This is because formulas are treated rather like
functions, with bindings coming into play when they are first defined,
not when they are first used. 

> 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.
> 
> 
 I will say that the long list of "reverse depends" on the survival
package does give me pause when making changes.

Terry T.



[Rd] How to deal with package conflicts
Terry Therneau