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

geta.data.frame(foo)

geta.data.frame(as.matrix(foo))

get_a.data.frame(as.tibble(foo))

There is no benefit. It is a rather cumbersome approach to checking whether
something behaves as you expect it to. `as.data.frame` will force it into
what you need; if it cannot be forced, then it will fail. That it can be
converted to a data.frame is the class' designers responsibility, not
yours. So you can use `as.data.frame` on *any* input that you need to
behave as a data.frame.
Consider a grouped tribble; now you have to test 2 different classes.

Kindly,
Stefan

Stefan McKinnon H?j-Edwards
ph.d. Genetics
+44 (0)776 231 2464
+45 2888 6598
Skype: stefan_edwards

2017-09-26 11:15 GMT+01:00 G?bor Cs?rdi <csardi.gabor at gmail.com>:

What is the benefit here, compared to just calling as.data.frame() on it?

Gabor

On Tue, Sep 26, 2017 at 11:11 AM, Daniel L?decke <d.luedecke at uke.de>
wrote:

Since tibbles add their class attributes first, you could use:

tb <- tibble(a = 5)
inherits(tb, "data.frame", which = TRUE) == 1

if "tb" is a data frame (only), TRUE is returned, for tibble FALSE. You

could then coerce to data frame: as.data.frame(tb)

-----Urspr?ngliche Nachricht-----
Von: R-package-devel [mailto:r-package-devel-bounces at r-project.org] Im

Auftrag von G?ran Brostr?m

Gesendet: Dienstag, 26. September 2017 12:09
An: r-package-devel at r-project.org
Betreff: Re: [R-pkg-devel] tibbles are not data frames



On 2017-09-26 11:56, G?bor Cs?rdi wrote:

On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys <Joris.Meys at ugent.be>

wrote:

I don't like the dropping of dimensions either. That doesn't change
the fact that a tibble reacts different from a data.frame. So tibbles
do not inherit correctly from the class data.frame, and it can thus
be argued that it's against OOP paradigms to pretend tibbles inherit
from the class data.frame.

I have yet to see an OOP system in which a subclass cannot override
the methods of its superclass. Not only is this in line with OOP
paradigms, it is actually one of the essential OOP features.

To be more constructive, if you have a function that only works with
data frame inputs, then it is good practice to check that the supplied
input is indeed a data frame. This is independent of tibbles.

It is not. I check input for being a data frame, but tibbles pass that

test. That's the essence of the problem.

In practice it seems to me that an easy fix is to just call
as.data.frame on the input. This should either convert it to a data
frame, or throw an error.

Sure, but I still need to rewrite the package.

G?rn

For tibbles it
drops the tbl* classes.

Gabor

Defensive coding techniques would check if it's a tibble and return
an error saying a data.frame is expected. Unless tibbles inherit
correctly from data.frame.

I have nothing against tibbles. But calling them "data.frame" raises
expectations that can't be fulfilled.

[...]