search

hadley / plyr

A R package for splitting, applying and combining large problems into simpler problems
plyr.had.co.nz
Other
494 stars 117 forks source link

Deprecate rename, count and mutate #252

Open krlmlr opened 9 years ago

krlmlr commented 9 years ago

for full (!) forward compatibility with dplyr. See http://krlmlr.github.io/pdlyr for an analysis.

hadley commented 9 years ago

I don't want to do that in this release as it would require a lot of downstream changes, but it seems like a reasonable idea.

krlmlr commented 9 years ago

Can we do it right after CRAN release then?

hadley commented 9 years ago

Yeah, although we'll need a plan for informing downstream maintainers. It would be helpful if you could estimate the amount of work by deprecating those functions and then running the revdep checks

krlmlr commented 9 years ago

How about adding now compatibility symbols in this release (rename -> prename et al.), to faciliate later migration?

I'll do the revdep checks.

hadley commented 9 years ago

Hmmmm, anything that requires deprecating existing (and popular) plyr functions is going to cause a lot of pain. I wonder if there's another approach

krlmlr commented 9 years ago

I guess you don't want to rename the corresponding dplyr verbs either. We could as well keep everything as is, and explicitly state this incompatibility. Do you think it's worth pursuing the compatibility package I started? I think such a separate glue is preferable to including this into dplyr.

By the same token -- there seem to be many requests for convenience functions in dplyr that can be implemented using the API. Do we already have a dplyrAlly?

krlmlr commented 9 years ago

revdep_check is flaky on my system, I'm trying for the third time now. ~There's https://github.com/skranz/dplyrExtras.~