more functions should be generic

[mgirlich]

while bringing some functions from tidyr to dbplyr I noticed that a couple of tidyr functions should probably be generic:

• uncount()

the pivot helpers would make sense as the dbplyr implemention of pivot_*() uses them anyway

• build_longer_spec()/build_wider_spec()
• pivot_longer_spec()/pivot_wider_spec()

data frame column helpers would make sense as nested tables in SQL are becoming more common (e.g. see tidyverse/dbplyr#515)

• pack()/unpack()
• unnest_longer()/unnest_wider()

list column helpers: not sure if they are needed but for completeness I also listed them here:

• chop()/unchop()
• hoist()

[abalter]

Any work on this so far?

[hadley]

@abalter if there was it would be noted in this issue.

[DavisVaughan]

As we've refined these new-ish verbs in the 1.2.0 release (tweaking defaults, adding arguments), it has been extremely helpful that they aren't generic so we don't have to deal with S3 methods in other packages needing changes (unlike some issues in the generic pivot_longer() and pivot_wider() #1291). I would encourage holding out as long as we can on this to really stabilize all of these verbs.

[mgirlich]

@DavisVaughan I see your point. Though, for lazy tables it would make sense to have pivot_wider_spec() be generic. Alternatively, they might have to export something like dbplyr_pivot_wider_spec() temporarily.

The issue with pivot_wider() is that the result has to be collected in order to know which columns to generate. Therefore, pivot_wider() cannot be lazy. In pivot_wider_spec() this is not an issue because we already know the columns. There are some issues in dbplyr: tidyverse/dbplyr#703 and tidyverse/dbplyr#598

[abalter]

Is there any chance nesting and pivoting will be available for lazy tables? Particularly database connections?