On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi <csardi.ga...@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.m...@ugent.be ------------------------------- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
