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

Joris Meys Joris.Meys at ugent.be
Tue Sep 26 13:18:59 CEST 2017

On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi <csardi.gabor at gmail.com>

> 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.

Fair enough. And I shouldn't have used the word "inherit" in the first
place, we're talking S3 after all. Fwiw, overriding a method to do the
exact same except for one detail isn't encouraged in the OOP world either.

> 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.

Actually it's not independent of tibbles as illustrated by others.
is.data.frame() returns TRUE for tibbles. It doesn't for matrices or

> 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. For tibbles it
> drops the tbl* classes.

This would also allow matrices or vectors to be converted to data.frames,
and that might or might not be warranted.

I agree that the S3 system allows you to do this, and think it's up to the
package manager to decide whether or not they would allow their users to
use tibbles instead of data.frame objects.

I think the bigger frustration is that tibble users are more prone to
expect all code to work exactly like it does with data.frames. Which it
obviously doesn't.

Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel : +32 9 264 59 87
Joris.Meys at Ugent.be
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list