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
