[Rd] Problems with ::

[Therneau, Terry M., Ph.D.]

In response to the tidyverse habit of adding another zillion functions to one's search space, the use of things like survival::coxph is becoming more common.  But this practice breaks the use of the specials argument in terms.formula, something that I make heavy use of in the survival package.   The following two pairs of models give different answers, and the second is wrong.

fit1a <- lm(GNP ~  Year + offset(Unemployed), longley)
fit1b<- lm(GNP ~  Year + stats::offset(Unemployed), longley)

fit1a <- survdiff(Surv(time, status) ~ rx + cluster(litter), rats)
fit1b <- survdiff(Surv(time, status) ~ rx + survival::cluster(litter), rats)
zed <- survival::cluster(rats$litter)
fit1c <- survdiff(Surv(time, status) ~ rx + zed, rats)

In the most recent CRAN version of survival I added some pre-processing steps that successfully catch fit1b, by stripping off  "survival::" from formulas before calling terms.formula.   But I can't prevent fit1c, and don't yet know if there are other case not covered by my current hack.  At least one of the CRAN packages that depends on survival has an example of exactly fit1c in their test suite.

The survival package uses the special argument a lot: strata, cluster, pspline, tt, frailty, and ridge.  I'm trying to think of a good plan for long term changes.   I list 3 below, and am hoping for better ideas or input.

a. Caveat emptor:  If you work hard to fool the specials argument, and succeed, then "Congratulations, you fooled the parser."

b. What I did early on with tt(), which is to make the function defition completely internal to coxph (the only survival function that uses tt).   People who type survival::tt or  survival:::tt get an error message.   A plus of this is that the error message will  wean users from pasting survival:: to everything inside a formula.   The disadvantages are first that it will break existing user code (most of which should be broken -- its not doing what they think), a second is that there may be use cases for strata, say, outside of a survival formula; it is essentially factor with shorter default labels.

c. Make all of these functions have a class, and rewrite the code to depend on the class rather than specials.  The Surv function is recognized in this way, so is not harmed by survival::Surv.  It is also why calling Surv to create a new variable is fine.  I'd still retain specials,  to support legacy code.

The more ornery part of me votes for b (what is the effect on help files)?    In any case a change won't happen overnight.
Do we leave offset in the caveat emptor group?
A small section needs to be added to the "user written packages" document, where it talks about specials.
What other packages use specials?

Terry T.







	[[alternative HTML version deleted]]