Hmm, the problem I see here is that these implied classes are all inherently
one-off. We also have
> inherits(matrix(1,1,1),"numeric")
[1] FALSE
> is.numeric(matrix(1,1,1))
[1] TRUE
> inherits(1L,"numeric")
[1] FALSE
> is.numeric(1L)
[1] TRUE
and if we start fixing one, we might need to fix all.
For method dispatch, we do have inheritance, e.g.
> foo.numeric <- function(x) x + 1
> foo <- function(x) UseMethod("foo")
> foo(1)
[1] 2
> foo(1L)
[1] 2
> foo(matrix(1,1,1))
[,1]
[1,] 2
> foo.integer <- function(x) x + 2
> foo(1)
[1] 2
> foo(1L)
[1] 3
> foo(matrix(1,1,1))
[,1]
[1,] 2
> foo(matrix(1L,1,1))
[,1]
[1,] 3
but these are not all automatic: "integer" implies "numeric", but "matrix" does
not imply "numeric", much less "integer".
Also, we seem to have a rule that inherits(x, c) iff c %in% class(x), 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....
-pd
> On 30 Oct 2019, at 12:29 , Martin Maechler <[email protected]> wrote:
>
> Note however the following historical quirk :
>
>> sapply(setNames(,1:5), function(K) inherits(array(pi, dim=1:K), "array"))
> 1 2 3 4 5
> TRUE FALSE TRUE TRUE TRUE
>
> (Is this something we should consider changing for R 4.0.0 -- to
> have it TRUE also for 2d-arrays aka matrix objects ??)
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [email protected] Priv: [email protected]
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
