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.onkel...@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.m...@ugent.be>: > > 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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
