Excellent suggestion, Ivan. Thanks for pointing out just where to look.
I stepped through tools::checkS3methods("pomp") and it does appear to be
roughly as I conjectured. Namely, all functions are extracted from the
pomp namespace and checked against a list of generics. The check that is
perform
(Sorry for the unfinished message. I've got to do something about my
mailer to make it harder to send them accidentally.)
On Fri, 6 Jan 2023 11:21:49 +0300
Ivan Krylov wrote:
> to see where 'filter' appears in the list of generics and where the
filter.traj function gets matched to it as a metho
On Thu, 5 Jan 2023 17:58:47 -0500
"Aaron A. King" wrote:
> However, since the S3 dispatch system is not itself confused, I
> suppose it must be the case that the S3 generic/method consistency
> checker itself is confused. I wonder, how does the checker decide
> when to throw a NOTE? Is it a sim
Thanks for the fast reply!
When I follow your suggestion above, I get
library(pomp)
dplyr::filter(structure(list(), class = 'traj'))
Error in UseMethod("filter") :
no applicable method for 'filter' applied to an object of class "traj"
Which is not what would happen if my filter.traj function
On Wed, 4 Jan 2023 15:54:52 -0500
"Aaron A. King" wrote:
> Why does inclusion of *dplyr* in the import list appear to trigger
> these warnings when they were not there before?
I think that's because dplyr itself contains an S3 generic named
"filter", and having a package namespace loaded (not ev
Hi all,
I'm modifying a package so as to remove its dependence on the superseded
packages *reshape2* and *plyr*, in favor of dependence on *dplyr*. In
particular, I'm just importing the one function `dplyr::bind_rows`.
A curious thing happens, however, as soon as I include this among the
imports
