From osklyar at ebi.ac.uk  Mon Feb 25 18:00:18 2008
From: osklyar at ebi.ac.uk (Oleg Sklyar)
Date: Mon, 25 Feb 2008 17:00:18 +0000
Subject: [Rd] Standard method for S4 object
In-Reply-To: <uy79957by.fsf@insightful.com>
References: <47C06F0A.4090505@u-paris10.fr> <uy79957by.fsf@insightful.com>
Message-ID: <47C2F422.6040608@ebi.ac.uk>

Hi Tim

Tim Hesterberg wrote:
> It depends on what the object is to be used for.
> 
> If you want users to be able to operate with the object as if it
> were a normal vector, to do things like mean(x), cos(x), etc.
> then the list would be very long indeed; for example, there are
> 225 methods for the S4 'bdVector' class (in S-PLUS), plus additional
> methods defined for inheriting classes.

This somehow undermines the whole idea of inheritance. If you do not 
inherit, then you are just implementing a class that mimics another one 
from scratch. However, the question then is not about standard methods 
any more, it's about the methods of the class that you mimic.

As an example, in my EBImage (image analysis, Bioconductor) the class 
"Image" is derived from "array" using contains="array", thus providing 
all the functionality of arrays on top of that of images without extra 
code. What I needed in this case was to redefine the [ operators and 
"Arith" ones as I wanted them to return objects of class "Image" instead 
of "array"; the [<- are actually fine. Print or plot work exactly the 
same as in arrays printing additional slots where appropriate if not 
redefined, as well as most of the ones you listed above like mean, cos, 
hist etc, just as the following example shows (the Math group NOT redefined)

> library(EBImage)
> x = Image(0.5,c(10,10))
> cos(x)

'Image'
   colorMode()   : Grayscale
   storage class : numeric 3D array, writable images in range [0..1]
   dim()         : 10x10
...

Surprisingly, there are things that didn't work out of the box, like for 
example median: I had to redefine it to work on the .Data slot directly, 
otherwise it took ages, but that was about the only problem.

> In cases like this you might prefer using an S3 class, using
> attributes rather than slots for auxiliary information, so that
> you don't need to write so many methods.

The reasoning here is not really clear. Could you please explain why is 
this better?

Best,
Oleg

> 
> Tim Hesterberg
> 
>> I am defining a new class. Shortly, I will submit a package with it. 
>> Before, I would like to know if there is a kind of "non official list" 
>> of what method a new S4 object should have.
>> More precisely, personally, I use 'print', 'summary' and 'plot' a lot. 
>> So for my new class, I define these 3 methods and of course, a get and a 
>> set for each slot. What else? Is there some other methods that a R user 
>> can reasonably expect? Some "minimum basic tools"...
>>
>> Thanks
>>
>> Christophe
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466



[Rd] Standard method for S4 object
Oleg Sklyar