[R-pkg-devel] Registered S3 methods from standard package
@eb@meyer @end|ng |rom |@u@de
Mon May 13 10:56:54 CEST 2019
I think your package can be useful. However, I'm with CRAN here in that
I would not want my standard graphics output to be changed just because
some package ("prettyB") gets loaded, which could happen
*unintentionally* as a dependency (or a dependency of a dependency, ...)
of another package.
What about some kind of prettyB::enable_prettyB() function which does
> registerS3method("plot", "default", prettyB::plot.default, asNamespace("graphics"))
similar to delayed method registration (see, e.g.,
https://github.com/r-lib/vctrs/blob/master/R/register-s3.R), so that a
user needs to switch to "prettyB" graphics explicitly ?
Resetting to graphics::plot.default should be made possible as well.
The question remains whether registerS3method() can be used at all,
since the help says:
> Internal namespace support functions. Not intended to be called
> directly, and only visible because of the special nature of the
> ‘base’ namespace.
Am 13.05.19 um 09:22 schrieb Colin Gillespie:
> Dear All,
> I'm developing a small package to make plotting methods a little bit
> nicer looking:
> The general idea is to replace plot.default() with an alternative
> (matching all arguments) and export. This would allow users to simply
> load the package and use base graphics functions as normal, but get a
> pretty graph.
> The general pattern I follow is:
> which then includes S3method(plot,default) in my NAMESPACE file. When
> building and checking the package I get
> Registered S3 methods from standard package(s) overwritten by 'prettyB':
> method from
> plot.default graphics
> which CRAN does not permit.
> Question: Is it possible to achieve the functionality I'm after
> (replacing the default plot.default() functions) while following the
> CRAN rules?
> R-package-devel using r-project.org mailing list
More information about the R-package-devel