From ggrothendieck at gmail.com  Fri Nov 25 17:28:34 2011
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Fri, 25 Nov 2011 11:28:34 -0500
Subject: [Rd] How to deal with package conflicts
In-Reply-To: <1322235424.5806.80.camel@nemo>
References: <mailman.21.1322218808.15358.r-devel@r-project.org>
	<1322230252.5806.15.camel@nemo> <4ECFAB1C.7040607@gmail.com>
	<1322235424.5806.80.camel@nemo>
Message-ID: <CAP01uRmcQ16A9r0npH_XNXFD-racQ91NOyqj72jzhwVTBWV=eg@mail.gmail.com>

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



[Rd] How to deal with package conflicts
Gabor Grothendieck