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
<davidhughjo...@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.ga...@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.luede...@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-boun...@r-project.org] Im
>> > Auftrag von Göran Broström
>> > Gesendet: Dienstag, 26. September 2017 12:09
>> > An: r-package-devel@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.m...@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.
>> >>
>> >> [...]
>> >>
>> >> ______________________________________________
>> >> R-package-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >>
>> >
>> > ______________________________________________
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >
>> > --
>> >
>> > _____________________________________________________________________
>> >
>> > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
>> > Rechts; Gerichtsstand: Hamburg | www.uke.de
>> > Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr.
>> > Dr. Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.)
>> > _____________________________________________________________________
>> >
>> > SAVE PAPER - THINK BEFORE PRINTING
>> > ______________________________________________
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
