[Rd] How to deal with package conflicts

[Gabor Grothendieck]

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