[Rd] How to deal with package conflicts

[Terry Therneau]

On Fri, 2011-11-25 at 09:50 -0500, Duncan Murdoch wrote:
> I think the general idea in formulas is that it is up to the user to 
> define the meaning of functions used in them.  Normally the user has 
> attached the package that is working on the formula, so the package 
> author can provide useful things like s(), but if a user wanted to 
> redefine s() to their own function, that should be possible.
> Formulas 
> do have environments attached, so both variables and functions should
> be 
> looked up there.
> 

I don't agree that this is the best way.  A function like coxph could
easily have in its documentation a list of the "formula specials" that
it defines internally.  If the user want something of their own they can
easily use a different word.  In fact, I would strongly recommend that
they don't use one of these key names.  For things that work across
mutiple packages like ns(), what user in his right mind would redefine
it?
  So I re-raise the question.  Is there a reasonably simple way to make
the survival ridge() function specific to survival formulas?  It sets up
structures that have no meaning anywhere else, and its global definition
stands in the way of other sensible uses.  Having it be not exported +
obey namespace type sematics would be a plus all around.   

Philosophical aside:
  I have discovered to my dismay that formulas do have environments
attached, and that variables/functions are looked up there.  This made
sensible semantics for predict() within a function impossible for some
of the survival functions, unless I were to change all the routines to a
model=TRUE default.  (And a change of that magnitude to survival, with
its long list of dependencies, is not fun to contemplate.  A very quick
survey reveals several dependent packages will break.) So I don't agree
nearly so fully with the "should" part of your last sentence.  The out
of context evaluations allowed by environments are, I find, always
tricky and often lead to intricate special cases. 
  Thus, moving back and forth between how it seems that a formula should
work, and how it actually does work, sometimes leaves my head
spinning.  

Terry T.


Terry Therneau