On 9/26/24 23:48, Murray Efford via R-package-devel wrote:
I am tossing up between (i) appealing to CRAN to allow the submission through
with NOTEs until it feels safe to remove the functions with misleading names
altogether, and (ii) removing them now and warning users about the new names in
an onLoad message.
A third solution would be to create a `esa.plot` method that redirects
the user to `esaPlot` etc. So you create a function `esa.plot`. Its
arguments should match those of the `esa` generic. If the `esaPlot`
function has completely different arguments, you could have this
`esa.plot` function give an error, redirecting the user to `esaPlot`.
You will still need to document the `esa.plot` function as a method to
prevent warnings/notes:
\usage{
\method{esa}{plot}(..)
}
And you should export it:
export(esa.plot)
So that it can be called directly. To prevent that the `esa.plot` is
called when a user passes a `plot` object to the `esa` generic, you
could use the solution mentioned below:
________________________________
From: Ivan Krylov <ikry...@disroot.org>
Theoretically speaking, if there was a place in your package where you
called the esa() generic with a user-supplied object, esa.plot() would
be a reachable S3 method, because the user would be able to construct
structure(list(), class = 'plot') and give it to your package code to
call esa(plot_object) and have it dispatched to esa.plot(). (Which
wouldn't be useful to the user, but that's how S3 works.)
In NAMESPACE you can do:
S3method(esa, plot, esaplotmethod)
To register `esaplotmethod` as the method that is called when using
`esa` with an object of type `plot`. This would prevent this issue.
However, this probably (can't test as the note doesn't happen on my
system) doesn't resolve the issue with the NOTE.
Best,
Jan
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
