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

Hadley Wickham h.wickham at gmail.com
Tue Sep 26 15:37:01 CEST 2017


On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström <goran.brostrom at umu.se> wrote:
> I am beginning to get complaints from users of my CRAN packages (especially
> 'eha') to the effect that they get error messages like "Error: Unsupported
> use of matrix or array for column indexing".
>
> It turns out that they are sticking in tibbles into functions that expect
> data frames as input. And I am using the kind of subsetting that Hadley
> dislikes (eha is an old package, much older than tibbles). It is of course a
> simple matter to change the code so it handles both data frames and tibbles
> correctly, but this affects many functions, and it will take some time. And
> when the next guy introduces 'troubles' as an improvement of 'tibbles', I
> will have to rewrite the code again.

Changing df[, x] to df[[x]] is not very hard and makes your code
easier to understand because it more clearly conveys the intent that
you want a single column.

> While I like Hadley's way of doing it, I think it is a mistake to let a
> tibble also be of class data frame. To me it is a matter of inheritance and
> backwards compability: A tibble should add nice things to a data frame, not
> change basic behaviour, in order to call itself a data frame.
>
> Is it correct to let a tibble be of class "data.frame"?

If it not inherit from data frame, it would be not work with the 99%
of functions that work with data frames and don't deliberately take
advantage of the dropping behaviour of [. In other words, it would be
pointless.

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.

Hadley

-- 
http://hadley.nz



More information about the R-package-devel mailing list