write dplyr verb methods for mapvizier sub-classes (cdf, growth df)

[almartin82]

per this comment and hadley's comment on dplyr, we write our own wrappers for the dplyr verbs.

thinking about this a bit, my one concern here is dispatch... because of namespace collisions in the tidyverse, lots of people (myself included) have gotten into the habit of being explicit about our dplyr calls... if an end user calls dplyr::select() on a mapviz$cdf object, it will still lose its class... but at least our summary methods will preserve the class of the object, because we can be explicit about using our internal wrappers? thinking out loud here.

[almartin82]

Hi @jwdink, I've found your advice about this problem on this thread very helpful!

I wrote up a toy question here to try to get a clear worked example on custom dplyr method dispatch. If you have a second, would you be able to take a look? Thanks!

[almartin82]

...and we've got a solution! thanks all.

[almartin82]

verbs to clean up

• [x] select
• [x] filter
• [x] group by
• [x] ungroup
• [x] arrange
• [x] mutate
• [x] summarize

[almartin82]

closed, finally :100:

[jwdink]

Don't forget dplyr::slice!

[almartin82]

Thank you!

[almartin82]

@chrishaid there's been some great new writeups on this issue here and here by @jwdink. Jacob - thank you!

it seems like we need to:

• [ ] implement the generic preservatively function that @jwdink wrote up
• [ ] strip out references to the underscore (eg mutate_) family of verbs in dplyr, as those are deprecated in dplyr 0.7

[jwdink]

Oops! FYI @almartin82, I just spotted a problem. You shouldn't use preservatively unless this can be sorted out.

Preservatively assumes the first argument is x:

preservatively <- function(fun) {
  function(x, ...) {
    result <- NextMethod()
    reclass(x, result)
  }
}

But most dplyr verbs have .data as their first arg. If the user calls the verb with an unnamed first argument, there's no issue. But if they call, e.g., filter(.data=foo, condition), then preservatively gets confused.

Changing that x in preservatively to .data would fix the problem for most dplyr verbs, but I think this issue suggests an adverb may not be appropriate after all.

I'll let you know if I figure something out.

It looks like the latest version of Advanced R addresses this issue (reconstruct is similar to reclass). See http://adv-r.hadley.nz/s3.html#methods