From g@bembecker @end|ng |rom gm@||@com  Fri Mar 29 05:05:40 2019
From: g@bembecker @end|ng |rom gm@||@com (Gabriel Becker)
Date: Thu, 28 Mar 2019 21:05:40 -0700
Subject: [Rd] Discrepancy between is.list() and is(x, "list")
In-Reply-To: <CAB8pepy8cyQ1pyN72kG2tta+kq9HUMU6XZy=aP8x9LyJOvehzA@mail.gmail.com>
References: <CAB8pepyU2qbU7fd1J9J6kyr_657PHFYHoJV6fnvNiHqqjq-24w@mail.gmail.com>
 <EB8494AA-8DAA-4B9A-B636-7E979251EF0C@ucsd.edu>
 <CAB8pepxp9TL18vvHajvSJBXhJY=E13ZWUjebxv6OdgPXcWVPTQ@mail.gmail.com>
 <CAD4oTHFMC=9__Qn=4CVjotHnVDoZii1KBx_ckbZ=74ATgtZYcQ@mail.gmail.com>
 <CAB8pepznVQ6jG2Lx4sJw3GS5xMS7u3jeVn3BxaR9e122NdV=uA@mail.gmail.com>
 <CAD4oTHE7gvHrB_WFinvvhTFpNrxyuMBqyjntB58-cu12KprwGA@mail.gmail.com>
 <CAB8pepy8cyQ1pyN72kG2tta+kq9HUMU6XZy=aP8x9LyJOvehzA@mail.gmail.com>
Message-ID: <CAD4oTHEX2xiY3KCtwo0k7FeegA-hxXtQsoOUDxp+hX=Gr3-MeQ@mail.gmail.com>

Abs,

Inline.

On Thu, Mar 28, 2019 at 8:10 PM Abs Spurdle <spurdle.a at gmail.com> wrote:

> I know I said that I had no further comments on object oriented semantics.
> However, I found a contradiction in the R documentation.
>
>
> Gabriel Becker wrote:
> > So, there are implicit classes, but *only when the data object is NOT an
> "R object"
>
> In the R Language Definition:
> > The R specific function typeof returns the type of an R object.
> > Lists have elements, each of which can contain any type of R object
> > Symbols refer to R objects.
> > Unlike most other R objects, environments are not copied
>
> So, according the the R Language Defintion, all objects in R, are R
> objects.
>
> However, in the help page for UseMethod(), which you've already mentioned:
> > An R object is a data object which has a class attribute (and this can
> be tested by is.object).
>
> So, according to this, an object in R, isn't necessarily an R object.
>
> These are contradictory to each other.
> And I believe that the R Language Definition is correct.
> So, the help page for UseMethod() should be changed to match the language
> definition.
>

This could be changed, but it seems largely semantic. Its clear from the
UseMethod documentation that it has a specific definition of "R Object",
that it explicitly defines, that it will use throughout that piece of
documentation. Unfortunate, perhaps, but clearly scoped and unambiguous, in
my opinion.

Also, note that if this was changed, its the documentation that would be
changed, to simply use, for example "classed object" instead of "R Object".
The behavior would be identical and would not change so that all "R
objects" (in the language definition sense) would be treated the same by S3
dispatch.


>
> Hadley Wickham wrote:
> > Understanding the distinction between base types and S3 classes
> > is very important to make this sort of question precise
>
> Note that the R Language Definition does not mention either "base types"
> or "S3 classes".
> So, should I be understanding *your* distinction between them?
>

They are not Hadley's distinction, or mine. We (he in more detail and
covering the corner cases like internal and group generics better) are
describing to you how the system actually works, and why you got the
results which so surprised you.

I think we've done so at this point however, and your phrasing makes it
seem like you're looking for an argument, which I (and I suspect others on
this list) have no interest in, rather than to learn, which I was happy to
try to help you with, so with respect I'll not be engaging you more on this
topic.


>
> Martin Maechler wrote:
> > I do agree with Gabe that (in some cases), using
> > formal (aka "S4") classes is really what one should do
>
> S4 doesn't always do intuitive things, either.
>
> Try the following example:
> > library (Matrix)
> > m = Matrix (1:24, 4, 6)
>
> > #expected output
> > print (m)
>
> > #not expected output
> > print (m, quote=FALSE)
>

So the correct way to print S4 objects is with show(), not print. A
cursory, non-comprehensive look at print.c (do_defaultprint) suggests to me
that print (or rather the c code called by print.default) handles S4
objects when the print call can essentially be transformed in-place to a
show call and then evaluated. That is the case where no additional
arguments are passed to print:

  if (*noParam*s && IS_S4_OBJECT(x) && isMethodsDispatchOn())
PrintObject(x, &data);
 else
PrintValueRec(x, &data);


So it has nothing to do with what argument is used, or the quote argument
in particular, at all:

>* print(x, quote = TRUE)*

<S4 Type Object>

attr(,"x")

 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

attr(,"Dim")

[1] 4 6

attr(,"Dimnames")

attr(,"Dimnames")[[1]]

NULL


attr(,"Dimnames")[[2]]

NULL


attr(,"factors")

list()

attr(,"class")

[1] "dgeMatrix"

attr(,"class")attr(,"package")

[1] "Matrix"


> *print(x, quote = FALSE)*

<S4 Type Object>

attr(,"x")

 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

attr(,"Dim")

[1] 4 6

attr(,"Dimnames")

attr(,"Dimnames")[[1]]

NULL


attr(,"Dimnames")[[2]]

NULL


attr(,"factors")

list()

attr(,"class")

[1] dgeMatrix

attr(,"class")attr(,"package")

[1] Matrix


> *print(x, digits = 5)*

<S4 Type Object>

attr(,"x")

 [1]  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

attr(,"Dim")

[1] 4 6

attr(,"Dimnames")

attr(,"Dimnames")[[1]]

NULL


attr(,"Dimnames")[[2]]

NULL


attr(,"factors")

list()

attr(,"class")

[1] "dgeMatrix"

attr(,"class")attr(,"package")

[1] "Matrix"


But basically, don't call print on S4 objects, call show, and everything
should work fine.

Best,
~G




> However, I still may consider using S4, especially where I would otherwise
> use a named list.
>
>
>

	[[alternative HTML version deleted]]



[Rd] Discrepancy between is.list() and is(x, "list")
Gabriel Becker