An R namespace acts as the immediate environment for all functions in its associated package. In other words, when function bar()
from package foo calls another function, the R evaluator first searches for the other function in <environment: namespace:foo>
, then in "imports.foo"
, <environment: namespace:base>
, <environment: R_GlobalEnv>
, and so on down the search list returned by typing search()
.
One nice aspect of namespaces is that they can make packages act like better citizens: unexported functions in <environment: namespace:foo>
and functions in imports:foo
are available only: (a) to functions in foo; (b) to other packages that import from foo; or (c) via fully qualified function calls like foo:::bar()
.
Or so I thought until recently...
The behavior
This recent SO question highlighted a case in which a function well-hidden in its package's namespace was nonetheless found by a call to a seemingly unrelated function:
group <- c("C","F","D","B","A","E")
num <- c(12,11,7,7,2,1)
data <- data.frame(group,num)
## Evaluated **before** attaching 'gmodels' package
T1 <- transform(data, group = reorder(group,-num))
## Evaluated **after** attaching 'gmodels
library(gmodels)
T2 <- transform(data, group = reorder(group,-num))
identical(T1, T2)
# [1] FALSE
Its immediate cause
@Andrie answered the original question by pointing out that gmodels imports from the the package gdata, which includes a function reorder.factor
that gets dispatched to inside the second call to transform()
. T1
differs from T2
because the first is calculated by stats:::reorder.default()
and the second by gdata:::reorder.factor()
.
My question
How is it that in the above call to transform(data, group=reorder(...))
, the dispatching mechanism for reorder
finds and then dispatches to gdata:::reorder.factor()
?
(An answer should include an explanation of the scoping rules that lead from a call involving functions in the stats and base packages to a seemingly well-hidden method in gdata.)
Further possibly helpful details
Neither
gdata:::reorder.factor
, nor the gdata package as a whole are explicitly imported by gmodels. Here are theimport*
directives in gmodels' NAMESPACE file:importFrom(MASS, ginv) importFrom(gdata, frameApply) importFrom(gdata, nobs)
There are no methods for
reorder()
ortransform()
in<environment: namespace:gmodels>
, nor in"imports:gmodels"
:ls(getNamespace("gmodels")) ls(parent.env(getNamespace("gmodels")))
Detaching gmodels does not revert
reorder()
's behavior:gdata:::reorder.factor()
still gets dispatched:detach("package:gmodels") T3 <- transform(data, group=reorder(group,-num)) identical(T3, T2) # [1] TRUE
reorder.factor()
is not stored in the list of S3 methods in the base environment:grep("reorder", ls(.__S3MethodsTable__.)) # integer(0)
R chat threads from the last couple of days include some additional ideas. Thanks to Andrie, Brian Diggs, and Gavin Simpson who (with others) should feel free to edit or add possibly impt. details to this question.