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

Dear all,

IMHO the problem is being look at from the wrong perspective. The
tibble doesn't change the data.frame, it uses all methods from
data.frame which it doesn't implement itself. Hence it behaves like at
data.frame to some extent.

If a package requires a data.frame, then it is up to the _user_ to
provide a data.frame (and a tibble is not a data.frame). Documenting
this in the package documentation/FAQ or issuing a warning "don't use
tibble" when the package is loaded should be sufficient.

Best regards,

ir. Thierry Onkelinx
Statisticus/ Statistician

Vlaamse Overheid / Government of Flanders
INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE
AND FOREST
Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
thierry.onkelinx at inbo.be
Kliniekstraat 25, B-1070 Brussel
www.inbo.be

///////////////////////////////////////////////////////////////////////////////////////////
To call in the statistician after the experiment is done may be no
more than asking him to perform a post-mortem examination: he may be
able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does
not ensure that a reasonable answer can be extracted from a given body
of data. ~ John Tukey
///////////////////////////////////////////////////////////////////////////////////////////


Van 14 tot en met 19 december 2017 verhuizen we uit onze vestiging in
Brussel naar het Herman Teirlinckgebouw op de site Thurn & Taxis.
Vanaf dan ben je welkom op het nieuwe adres: Havenlaan 88 bus 73, 1000 Brussel.

///////////////////////////////////////////////////////////////////////////////////////////


2017-09-26 13:18 GMT+02:00 Joris Meys <Joris.Meys at ugent.be>:

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

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

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

______________________________________________
R-package-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel