[R-pkg-devel] tibbles are not data frames
On 26/09/2017 4:52 PM, Jens Oehlschl?gel wrote:
On 26.09.2017 15:37, Hadley Wickham wrote:
I decided to make [.tibble type-stable (i.e. always return a data frame) because this behaviour causes substantial problems in real data analysis code. I did it understanding that it would cause some package developers frustration, but I think it's better for a handful of package maintainers to be frustrated than hundreds of users creating dangerous code.g Hadley
If that is right -- and I tend to believe it is right -- this change had better been done in R core and not on package level. I think the root of this evil is design inconsistencies of the language together with the lack of removing these inconsistencies. The longer we hesitated, the more packages such a change could break. The lack of addressing issues in R core drives people to try to solve issues on package level. But now we have two conflicting standards, i.e. a fork-within-the-language: Am I a member of the tidyverse or not? Am I writing a package for the tidyverse or for standard-R or for both. With a fork-of-the-language we would at least have a majority vote for one of the two and only the fitter would survive. But with a fork-within-the-language 'R' gets more and more complex, and working with it more and more difficult. There is not only the tidyverse, also the Rcppverse and I don't know how many other verses. If there is no extinction of inconsistencies in R, not sufficient evolution in R, but lots of evolution in Julia, evolution will extinct R together with all its foobarverses in favor of Julia (or Python). May be that's a good thing. I think tibble should respect drop=TRUE and respect the work of all package authors who wrote defensive code and explicitly passed drop= instead of relying on the (wrong) default. Again: better would be a long-term clean-up roadmap of R itself and one simple standard called 'data.frame'. Instead of forking or betting on any particular foobarverse: why not have direct democratic votes about certain critical features of such a long-term roadmap in such a big community?
I think R Core would not be interested in a vote, because you'd be voting to give them work to do, and that's really rude. What would have a better chance of success would be for someone to write a short article describing the proposal in detail, and listing all changes to CRAN and Bioconductor packages that would be necessary to implement it. That's a lot of work! Do you have time to do it? Duncan Murdoch