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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
