[R-pkg-devel] tibbles are not data frames

[Duncan Murdoch]

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