We are building a package, and want to create S4 methods for both head and mean for our own BigMatrix class. Following the recommendation in "Writing R Extensions" we use exportMethods instead of export in NAMESPACE (this is described as being "clearer"). This works for head, but not for mean. Obviously we importFrom(utils, head), but don't need to do this for mean, which is imported automatically from base. If we export(mean) rather than exportMethods(mean), it works as intended. A similar problem arises for a new generic function and an associated method, colmean, where the use of exportMethods(colmean) fails, but export(colmean) succeeds. We can build and use the package by using export instead of exportMethods, but we suspect that we're missing something that might be important to understand. Any hints or links to something we missed would be appreciated. Thanks, Jay Emerson Michael Kane -- John W. Emerson (Jay) Assistant Professor of Statistics Director of Graduate Studies Department of Statistics Yale University http://www.stat.yale.edu/~jay [[alternative HTML version deleted]]
On Sat, 8 Dec 2007, Jay Emerson wrote:> We are building a package, and want to create S4 methods for both head and > mean for our own BigMatrix class. Following the recommendation in "Writing > R Extensions" we use exportMethods instead of export in NAMESPACE (this is > described as being "clearer"). This works for head, but not for mean. > Obviously we importFrom(utils, head), but don't need to do this for mean, > which is imported automatically from base.And what is the error message?> If we export(mean) rather than exportMethods(mean), it works as intended. > A similar problem arises for a new generic function and an associated > method, colmean, where the use of exportMethods(colmean) fails, but > export(colmean) succeeds. > > We can build and use the package by using export instead of exportMethods, > but we suspect that we're missing something that might be important to > understand. > > Any hints or links to something we missed would be appreciated.I know there are problems if you define a generic and no methods in a package (that is what stats4 does for AIC), but it doesn't sound as if that is what you are doing. (Since the introduction of implicit generics - which may well apply to your mean() - it is possible to define a generic in a package without any methods stored there, not even a default method.) I saw nothing in your description that is different from several other pacakges. Without either the error messages or an example, we are reduced to guessing. Can you make a minimal version available to us to look at? -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
At Brian Ripley's request, I started putting together a minimal package to
illustrate the problem (see below for my original post). As usually
happens, I have stumbled on the problem: our zzz.R file contained the
command:
.noGenerics <- TRUE
which we probably copied blindly from some example. After removing this I
was able to use exportMethods(mean) instead of export(mean), as
recommended. In case others find this helpful, I copy the following, which
I found in the help file for library {base}.
"
Formal methods
library takes some further actions when package methods is attached (as it
is by default). Packages may define formal generic functions as well as
re-defining functions in other packages (notably base) to be generic, and
this information is cached whenever such a package is loaded after
methodsand re-defined functions are excluded from the list of
conflicts. The check
requires looking for a pattern of objects; the pattern search may be avoided
by defining an object .noGenerics (with any value) in the package.
Naturally, if the package *does* have any such methods, this will prevent
them from being used.
"
Regards,
Jay
On Dec 8, 2007 4:12 PM, Jay Emerson <jayemerson@gmail.com> wrote:
> We are building a package, and want to create S4 methods for both head and
> mean for our own BigMatrix class. Following the recommendation in
"Writing
> R Extensions" we use exportMethods instead of export in NAMESPACE
(this is
> described as being "clearer"). This works for head, but not for
mean.
> Obviously we importFrom(utils, head), but don't need to do this for
mean,
> which is imported automatically from base.
>
> If we export(mean) rather than exportMethods(mean), it works as intended.
>
> A similar problem arises for a new generic function and an associated
> method, colmean, where the use of exportMethods(colmean) fails, but
> export(colmean) succeeds.
>
> We can build and use the package by using export instead of exportMethods,
> but we suspect that we're missing something that might be important to
> understand.
>
> Any hints or links to something we missed would be appreciated.
>
> Thanks,
>
> Jay Emerson
> Michael Kane
>
>
> --
> John W. Emerson (Jay)
> Assistant Professor of Statistics
> Director of Graduate Studies
> Department of Statistics
> Yale University
> http://www.stat.yale.edu/~jay
>
--
John W. Emerson (Jay)
Assistant Professor of Statistics
Director of Graduate Studies
Department of Statistics
Yale University
http://www.stat.yale.edu/~jay
[[alternative HTML version deleted]]