You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is easy to support other classes with methods for mutate_, summarise_, mutate_at etc. *_if() variants, however, do not work with databases and we are unable to directly support it in spatial objects in spdplyr. Here are some thoughts from @lionel- :
The easy fix is to make probe_colwise_names() an exported generic. I'm not sure we want to abstract out function mapping in the dplyr interface though. So I don't know what can be done here.
Maybe have a generic map in purrr. I think we need a s3map() family in purrr. But until purrr depends on dplyr (there are plans to decouple) we can't have dplyr depend on purrr anyway.
Lets make probe_colwise_names() generic. We'll just need to come up with a slighter shorter name. It might be reasonable for the default method to call collect() or as.data.frame() (for data bases, n will need be set to a small number), since I think most often the predicates are used for type information.
hadley
changed the title
*_if() functions not based on generics
Rename and export probe_colwise_names
Feb 21, 2017
It is easy to support other classes with methods for
mutate_
,summarise_
,mutate_at
etc.*_if()
variants, however, do not work with databases and we are unable to directly support it in spatial objects inspdplyr
. Here are some thoughts from @lionel- :mdsumner/spdplyr#10 (comment)
The text was updated successfully, but these errors were encountered: