Message-ID: <CABdHhvGmY+L2pb6DY-A2FmMBcA07OnP9fr_xvTmuwB7=jNmu3w@mail.gmail.com>
Date: 2017-09-26T13:33:02Z
From: Hadley Wickham
Subject: [R-pkg-devel] tibbles are not data frames
In-Reply-To: <CABFfbXtEaX0moo7D3VuP=K33zCj63e2Z-kzUhQC=iSdod7bT4g@mail.gmail.com>
On Tue, Sep 26, 2017 at 8:28 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote:
> On Tue, Sep 26, 2017 at 11:56 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
>>
>> On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys <Joris.Meys at 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.
>
> Not if this compromises type safety. Formal OOP languages enforce the
> signature matches when you override a method. The fact that R is
> dynamically typed puts this responsibility at the developer. The fact
> that tibble [ returns a data frame where it's parent class returns an
> atomic vector violates this principle, resulting in the obvious type
> errors where tibbles are used as data frames.
Where its parent class _sometimes_ returns an atomic vector and
_sometimes_ returns a data frame.
Hadley
--
http://hadley.nz