[Rd] S4 / S3 / Sweave problem

[Prof Brian Ripley]

On Mon, 5 May 2008, Martin Maechler wrote:

>>>>>> "PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
>>>>>>     on Sun, 04 May 2008 21:46:18 -0400 writes:
>
>    PaulG> Prof Brian Ripley wrote:
>    >> I'm not sure what the issue being asked about here is.  The peculiar
>    >> printing I don't see and may well be a locale issue.  (Is this UTF-8 and
>    >> TeX has not been told so?)
>
>    PaulG> It seems to happen in locales UTF-8, POSIX and C.  I have not tried others.
>
>    >>
>    >> The other issue is that when printing an object with attributes, there
>    >> is no consideration of S4 classes amongst the attributes.  That was
>    >> either an undocumented design decision or an omission.  This is
>    >> different from
>    >>
>    >>> print(attributes(zz))
>    >> $tsp
>    >> [1]  1 10  1
>    >>
>    >> $class
>    >> [1] "ts"
>    >>
>    >> $Meta
>    >> An object of class “TSmetax”
>    >> Slot "serIDs":
>    >> [1] "whatever"
>    >>
>    >> Slot "ExtractionDate":
>    >> NULL
>    >>
>    >> since although attributes are internally a pairlist and printed by a
>    >> special C function, attributes() returns a list.
>    >>
>    >> It would be fairly easy to include a branch for S4 objects, but there
>    >> are ambuiguities still over what they are (I wrote up a set of questions
>    >> over a year ago about this).  But it would seem fairly safe to send them
>    >> to show() in the same circumstances that autoprinting does for
>    >> apparently S4 objects.
>
>    PaulG> Yes, I do have the impression that print() does not do exactly what one
>    PaulG> might like when it finds an S4 attribute in an S3 object. I hope this is
>    PaulG> not a design decision. It would make it very difficult to migrate toward
>    PaulG> S4 if it is not possible to include S4 objects in S3 objects this way.
>
> I'm pretty sure that this has *not* been a design decision, but
> rather an oversight till now.
>
> To me, it seems even a "natural" oversight: If you are working
> for fully designed classes, it seems awkward to simultaneously
> use attributes of S3- (or "no class"-) objects.
> I do understand though that there can be situations, in
> particular migrations ones, where you want to do this ... and
> should be allowed to and should see print() working.

But you do!  The issue is that S4 uses show() and not print(), and it was 
print() that is being called.  And the nub is

> print(z)
An object of class “TSmetax”
Slot "serIDs":
[1] "whatever"

Slot "ExtractionDate":
NULL

calls show() whereas we have

> print(z, digits=7)
<S4 Type Object>
attr(,"serIDs")
[1] "whatever"
attr(,"ExtractionDate")
`NULL`
attr(,"class")
[1] "TSmetax"
attr(,"class")attr(,"package")
[1] ".GlobalEnv"

This happens in print(zz) because printAttributes calls print() with a 
'digits' setting -- it has to because it does not know where it is called 
from.

It does seem reasonable for print(zz) to do as it did: the real problem is 
that show(zz) does not work correctly.

I've altered printAttributes in r-devel to call show() on S4 objects, but 
that does mean that arguments such as 'digits' will not be respected.
(There is potentially a problem if show() then calls print() which I have 
yet to analyse.)

>
> Martin
>
>
>    >> On Sun, 4 May 2008, Paul Gilbert wrote:
>    >>
>    >>> I'm not sure if this as a bug or something I am doing wrong. It occurs
>    >>> in both 2.7.0 and 2.6.2.
>    >>
>    >> My guess is that it was never intended that S4 objects be used as
>    >> attributes, in the same way that one of the unanswered questions is if S4
>    >> objects should be allowed to have attributes (other than slots).
>    >>
>    >>>
>    >>> require("methods")
>    >>>
>    >>> setClassUnion("OptionalPOSIXct",   c("POSIXct",   "NULL"))
>    >>>
>    >>> setClass("TSmetax",
>    >>> representation(serIDs="character", ExtractionDate="OptionalPOSIXct" ))
>    >>>
>    >>> setGeneric("TSmetax",
>    >>> def= function(x, ...) standardGeneric("TSmetax"))
>    >>>
>    >>> setMethod("TSmetax",   signature(x="character"),
>    >>> definition= function(x, ...){
>    >>> new("TSmetax", serIDs=x, ExtractionDate=Sys.time())
>    >>> } )
>    >>>
>    >>>> z <- new("TSmetax", serIDs="whatever", ExtractionDate= NULL)
>    >>>> print(z)
>    >>> An object of class "TSmetax"
>    >>> Slot "serIDs":
>    >>> [1] "whatever"
>    >>>
>    >>> Slot "ExtractionDate":
>    >>> NULL
>    >>>
>    >>> Now if I make this an attribute of an S3 class an print, I get
>    >>>> zz <- ts(1:10)
>    >>>> attr(zz, "Meta") <- z
>    >>>> print(zz)
>    >>> Time Series:
>    >>> Start = 1
>    >>> End = 10
>    >>> Frequency = 1
>    >>> [1]  1  2  3  4  5  6  7  8  9 10
>    >>> attr(,"Meta")
>    >>> <S4 Type Object>
>    >>> attr(,"serIDs")
>    >>> [1] "whatever"
>    >>> attr(,"ExtractionDate")
>    >>> `
NULL
`
>    >>> attr(,"class")
>    >>> [1] "TSmetax"
>    >>> attr(,"class")attr(,"package")
>    >>> [1] ".GlobalEnv"
>    >>>>
>    >>>
>    >>> The `
NULL
` shows up i
>    >>> shows up in the tex file generated by a vignette as
>    >>> <soh>NULL<soh> which causes  tex (pdftex) to throw an  error.
>    >>> (It also seems to mess up my mail tool, so I hope this goes through.)


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595