From h@w|ckh@m @end|ng |rom gm@||@com  Thu Nov 14 14:47:27 2019
From: h@w|ckh@m @end|ng |rom gm@||@com (Hadley Wickham)
Date: Thu, 14 Nov 2019 07:47:27 -0600
Subject: [Rd] class(<matrix>) |--> c("matrix",
 "arrary") [was "head.matrix ..."]
In-Reply-To: <24007.52264.596794.767557@stat.math.ethz.ch>
References: <CAPRVBcxsAkcgr3mDc4skTe8DTxJaYe2xyhk3QMk3odW1MGcyNA@mail.gmail.com>
 <CAB8pepxS2mRtd+522OwjixnM6ZjYxb+X0dc4vMGn6QxdFYBmVQ@mail.gmail.com>
 <CAD4oTHH=LpeEj6h6xYdOGsreS-GDCGdgJV5wpaUR3Pjuh5_M1w@mail.gmail.com>
 <CAPRVBczYZHO3JaFVfNeNNV0-YMRvX3CUYhUvLCjophDEoP+XgQ@mail.gmail.com>
 <23935.14449.965488.684663@stat.math.ethz.ch>
 <CAPRVBcwMY=GAVfFeCwowQsxP31Y=_B2ducosThN+8V91WESB8Q@mail.gmail.com>
 <20449_1568703158_x8H6qIDG009669_f8285123-371f-5d4b-1281-6cc085dba122@fredhutch.org>
 <22204_1568723392_x8HCSG3F015456_674779E0-B1F6-4DC2-9F1C-D5D48B044B66@mcmaster.ca>
 <AD725242-0FB7-4004-9F16-304E345A363A@mcmaster.ca>
 <23937.1791.389379.103733@stat.math.ethz.ch>
 <CAD4oTHF_e4rtHu0S5bUu38+kQSEHXwun3Sv9-CbK+xN9tSc2hA@mail.gmail.com>
 <CAD4oTHFf7Zp+Xe3jvv7oirLWgZm7ZiSNWZvbrEsqJGfrL6Q2wQ@mail.gmail.com>
 <23993.29737.690600.313456@stat.math.ethz.ch>
 <38105A28-07AE-48F6-A4A4-0C1FCCCBFBDC@gmail.com>
 <23995.62027.969336.196344@stat.math.ethz.ch>
 <CAD4oTHF1+PdJX-Qq=JZwafhGNatDu9AZVD0prCAvyJFL9bLzVg@mail.gmail.com>
 <24007.52264.596794.767557@stat.math.ethz.ch>
Message-ID: <CABdHhvEzVtwajH3fRD_ZOzChf6kVr2j3j6dD-Uo2i92Vj9kTtQ@mail.gmail.com>

On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>
> >>>>> Gabriel Becker
> >>>>>     on Sat, 2 Nov 2019 12:37:08 -0700 writes:
>
>     > I agree that we can be careful and narrow and still see a
>     > nice improvement in behavior. While Herve's point is valid
>     > and I understand his frustration, I think staying within
>     > the matrix vs c(matrix, array) space is the right scope
>     > for this work in terms of fiddling with inheritance.
>
>  [.................]
>
>
> > > Also, we seem to have a rule that inherits(x, c)  iff  c %in% class(x),
> >
> > good point, and that's why my usage of  inherits(.,.) was not
> > quite to the point.  [OTOH, it was to the point, as indeed from
> >       the ?class / ?inherits docu, S3 method dispatch and inherits
> >       must be consistent ]
> >
> >     > which would break -- unless we change class(x) to return the whole
> > set of inherited classes, which I sense that we'd rather not do....
>
>   [................]
>
> > Note again that both "matrix" and "array" are special [see ?class] as
> > being of  __implicit class__  and I am considering that this
> > implicit class behavior for these two should be slightly
> > changed ....
> >
> > And indeed I think you are right on spot and this would mean
> > that indeed the implicit class
> > "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for  R 4.0.0   next April.

I can't seem to find the previous thread, so would you mind being a
bit more explicit here? Do you mean adding "array" to the implicit
class? Or adding it to the explicit class? Or adding it to inherits?
i.e. which of the following results are you proposing to change?

is_array <- function(x) UseMethod("is_array")
is_array.array <- function(x) TRUE
is_array.default <- function(x) FALSE

x <- matrix()
is_array(x)
#> [1] FALSE
x <- matrix()
inherits(x, "array")
#> [1] FALSE
class(x)
#> [1] "matrix"

It would be nice to make sure this is consistent with the behaviour of
integers, which have an implicit parent class of numeric:

is_numeric <- function(x) UseMethod("is_numeric")
is_numeric.numeric <- function(x) TRUE
is_numeric.default <- function(x) FALSE

x <- 1L
is_numeric(x)
#> [1] TRUE
inherits(x, "numeric")
#> [1] FALSE
class(x)
#> [1] "integer"

Hadley

-- 
http://hadley.nz



[Rd] class(<matrix>) |--> c("matrix", "arrary") [was "head.matrix ..."]
Hadley Wickham