How to deal with package conflicts
On Fri, Nov 25, 2011 at 10:37 AM, Terry Therneau <therneau at mayo.edu> wrote:
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.
The dynlm package uses formula functions which are specific to it. Look at its code.
Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com