Right. I believe that last time this topic came up (August last year) you said
that your preferred solution was to export the method but not the generic. I
think that's a good idea.
The reason that it doesn't work with filter is that when you created the
generic function filter in the dplyr pac
Hello,
I've noticed that dget() is much slower in the current and devel R
versions than in previous versions. In 2.15 reading a 1-row
data.frame takes less than half a second:
> (which.r <- R.Version()$version.string)
[1] "R version 2.15.2 (2012-10-26)"
> x <- data.frame(matrix(sample(letters
> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatch to "filter.test" will never occur.
Right, and this is as desired. If dplyr is not explicitly loaded by
the user, filter.
On Fri, 2014-06-20 at 01:34 -0500, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package...
Let's not go round in circles. I already pointed this out in my earlier
reply to Winston. It has been snipped from the thread history so I'l
On 20/06/2014, 8:34 AM, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package... Perhaps help() should be intelligent
> enough to link the documentation of `FUN` from package A for package B
> when B imports `FUN` from A, and exports
