On 04/29/2015 05:38 PM, William Dunlap wrote:
And in general a developer would avoid masking a function
in a base package, so as not to require the user to distinguish
between stats::density() and igraph::density(). Maybe the
example is not meant literally.
The 'filter' function in the popular 'dplyr' package masks the one
that has been in the stats package forever, and they have nothing
in common, so that may give you an example.
As I recall, several packages mask the simulate generic in stats, if you
are looking for examples.
Paul Gilbert
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Apr 29, 2015 at 1:24 PM, Martin Morgan <mtmor...@fredhutch.org>
wrote:
On 04/28/2015 01:04 PM, Gábor Csárdi wrote:
When a symbol in a package is resolved, R looks into the package's
environment, and then into the package's imports environment. Then, if the
symbol is still not resolved, it looks into the base package. So far so
good.
If still not found, it follows the 'search()' path, starting with the
global environment and then all attached packages, finishing with base and
recommended packages.
This can be a problem if a package uses a function from a base package,
but
it does not formally import it via the NAMESPACE file. If another package
on the search path also defines a function with the same name, then this
second function will be called.
E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
also defines 'density()', and 'igraph' is on the search path, then
'ggplot2' will call 'igraph::density()' instead of 'stats::density()'.
stats::density() is an S3 generic, so igraph would define an S3 method,
right? And in general a developer would avoid masking a function in a base
package, so as not to require the user to distinguish between
stats::density() and igraph::density(). Maybe the example is not meant
literally.
Being able to easily flag non-imported, non-base symbols would definitely
improve the robustness of package code, even if not helping the end user
disambiguate duplicate symbols.
Martin Morgan
I think that for a better solution, either
1) the search path should not be used at all to resolve symbols in
packages, or
2) only base packages should be searched.
I realize that this is something that is not easy to change, especially 1)
would break a lot of packages. But maybe at least 'R CMD check' could
report these cases. Currently it reports missing imports for non-base
packages only. Is it reasonable to have a NOTE for missing imports from
base packages as well?
[As usual, please fix me if I am missing or misunderstood something.]
Thank you, Best,
Gabor
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
