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

Yes, basically tibbles violate the substitution principle. A lot of
other packages do, probably base R as well, although it is sometimes
hard to say, because there is no clear object hierarchy.

Let's take a step back, and see how you can check for a data frame argument.

1. Weak check.

is.data.frame(arg)

This essentially means that you trust subclasses of data.frame to
adhere to the substitution principle. While this is nice in theory, a
lot packages (including both major packages implementing subclasses of
data.frame!) do not always adhere. So this is not really a safe
solution.

Base R does this as well, sometimes, e.g. aggregate.data.frame has:

     if (!is.data.frame(x))
         x <- as.data.frame(x)

which is essentially equivalent to the weak check, since it leaves
data.frame subclasses untouched.

2. Strong "check".

arg <- as.data.frame(arg)

This is safer, because it does not rely on subclass implementors. It
also has the additional benefit that your code is polymorphic: it
works with any input, as long as it can be converted to a data frame.

Base R also uses this often, e.g. in merge.data.frame:

     nx <- nrow(x <- as.data.frame(x))
     ny <- nrow(y <- as.data.frame(y))

Gabor

Disclaimer: I do not represent the tibble authors in any way.

On Tue, Sep 26, 2017 at 11:21 AM, David Hugh-Jones
<davidhughjones at gmail.com> wrote:

These replies seem to be missing the point, which is that old code has to be
rewritten because tibbles don't behave like data frames.

It is true that subclasses can override behaviour, but there is an implicit
contract that the same methods should do the same things.

The as.xxx pattern seems weird to me, though I see it a lot. What is the
point of inheritance if you always have to convert an object upwards before
you can treat it as a member of the superclass?

I can see this argument will run...

David

On 26 September 2017 at 11:15, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:

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.

[...]