>>>>> Gábor Csárdi <csardi.ga...@gmail.com> >>>>> on Wed, 29 Apr 2015 23:07:09 -0400 writes:
> On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert <pgilbert...@gmail.com> wrote: >> >> As I recall, several packages mask the simulate generic in stats, if you >> are looking for examples. >> > FWIW, here is a list of base* functions masked** by CRAN packages: > https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md > Look at the long table in the end. simulate indeed comes up 16 times. (But > read ** below.) > * This only includes functions in base packages that are attached by > default. > ** The CRAN function names were taken from the manual page aliases, so a > couple of them are not really function names, and some of them are probably > not masking anything, but defining an S3 generic. This was a lot simpler > than going over the namespaces of all CRAN packages. > It seems that several base functions are masked, by several packages. I > would need to get a better CRAN function list, though. Thank you Gabor. As Martin Morgan observed, many of these will be methods, S3 and S3 and there is often no conflict and no masking at all for all these, so I am claiming that your "statistics" are quite a bit biased, and probably most of the more common names are proper methods. There is another issue, I've wanted to raise, exemplified by my Rmpfr package [interface to the MPFR C library for high-accuracy floating point computations]: As it defines "mpfr"-ified versions of standard R functions many of which are *not* generic, it must mask them. E.g, currently, the following "are masked" messages (when attaching Rmpfr) are unavoidable Attaching package: ‘Rmpfr’ The following objects are masked from ‘package:stats’: dbinom, dnorm, dpois, pnorm The following objects are masked from ‘package:base’: pmax, pmin (Currently, there are also 'cbind' and 'rbind' being masked in order to work with mpfr-number matrices ... but that should in principle be avoidable) I think these "... are masked" messages are still appropriate: After all, pnorm() will really be taken from Rmpfr instead of from stats, and the user should know that she is trusting the author of Rmpfr (me) to do the right thing, when she calls pnorm(), namely to call the equivalent stats::pnorm() for standard numbers, and to call the MPFR-library code for mpfr-numbers. - - - - - - - - - - - - - - - - - - - - - - - - Now the above may have almost nothing to do with the original subject. If I have understood your main point correctly, you are suggesting that 'R CMD check' should start putting out a NOTE when package code calls a function from one of a set of "standard packages" (*) and the package author failed to use an importFrom(<standard pkg>, <function>) in his/her NAMESPACE. I agree that this would be useful. Actually, I think we have something like this in place already... but maybe not strictly enough (?) (*) IIUC, you suggested to use "standard packages" := packages which are attached by default in R, apart from package 'base' because that does come immediately after the imports anyway (and because you cannot explicity import from base). Martin Maechler ETH Zurich ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel