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