[R-pkg-devel] tibbles are not data frames
goran.brostrom at umu.se
Tue Sep 26 11:03:49 CEST 2017
On 2017-09-26 10:57, Stefan McKinnon Høj-Edwards wrote:
> Hi Göran,
> Could you please elaborate on which kind of subsetting that Hadley dislikes?
> I am yet to encounter operations on data frames that are not possible on
For instance, if 'dat' is a data frame, dat[1:3, 5] returns a vector of
length 3. If 'dat' is a tibble, you do dat[][1:3] to get the same
vector. A tibble never 'drops dimensions'. See Hadley's book, on the web.
> Stefan McKinnon Hoj-Edwards
> Stefan McKinnon Høj-Edwards
> ph.d. Genetics
> +44 (0)776 231 2464
> +45 2888 6598
> Skype: stefan_edwards
> 2017-09-26 8:30 GMT+01:00 Göran Broström <goran.brostrom at umu.se
> <mailto:goran.brostrom at umu.se>>:
> 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.
> 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"?
> Göran Broström
> R-package-devel at r-project.org <mailto:R-package-devel at r-project.org>
> mailing list
More information about the R-package-devel