[Rd] setGeneric for residuals, etc

[Martin Morgan]

On 01/24/2011 08:37 AM, Kasper Daniel Hansen wrote:
> Johann,
> 
> whether S4 is "better" than S3 is a heated subject.  No-one (I think)
> disputes that S4 is in some sense more flexible (for some suitable
> definition of flexible), but it does incur some performance overhead
> (how much is debatable) and some would argue that it also makes code
> more complicated and harder to debug.
> 
> But take a look at stats4.
> 
> Kasper
> 
> On Mon, Jan 24, 2011 at 11:01 AM, Johann Hibschman <jhibschman at gmail.com> wrote:
>> "Janko Thyson" <janko.thyson.rstuff at googlemail.com> writes:
>>
>>>> I'm experimenting with a few model-fitting classes of my own.  I'm
>>>> leaning towards using S4 for my classes, but the R functions I'd want
>>>> to override (residuals, predict, etc.) are all S3 methods.
>>
>>> For example, inside your method for 'residuals()', you will
>>> probably just get some data out of a slot of your object and run the S3
>>> function 'residuals(your.slot.data)'. So there's nothing that should make
>>> you nervous in that respect, you're not overwriting anything with your
>>> method. Setting a generic for an existing function is just a necessary step
>>> in order to specify S4 methods for it.
>>
>> Yes, I understand that it's a necessary step in R, but I'm still puzzled
>> as to why it's necessary.  (And by "why", I don't mean the technical
>> point that 'residuals' is not an S4 generic function; I mean why isn't
>> it a S4 generic function already?)
>>
>> In principle, R could be shipped with all S3 functions replaced by S4
>> functions that default to the S3 implementation.  That would be a
>> benefit to everyone writing S4 objects.  The fact that it's not been
>> done seems to imply it would have a cost to people writing S3 objects,
>> so I'm trying to understand what that cost is.

As Kasper mentioned the current S4 implementation has costs in terms of
performance and usability that I suppose make it unappealing as a
'built-in' feature of R.

The current situation, where individual package developers promote a
function to an S4 generic, can lead to many issues. Some of these
represent bugs in the implementation of S4, e.g., incorrect dispatch
with complicated class hierarchies and package dependencies, that are
very challenging for the average developer (me, for instance) to fathom.
There are also more conceptual issues, e.g., two packages can each
create generics that are exported from separate package name spaces,
with the usual rules of the R search path determining which generic is
discovered. This is very confusing to the user, who has been told that
they are using a 'generic'. Documentation is also very confusing, as the
generic is documented in several different places.

These issues become increasingly important as package hierarchies
required for analysis become complicated; the average CRAN package has
relatively few dependencies and for many there will be no problem. The
class hierarchy and collection of packages for a typical Bioconductor
analysis can be quite large and complicated, leading to subtle problems.

Martin

>>
>> Perhaps I'm seeing an implied risk where I really should be seeing a
>> loose federation of developers with disparate interests, and the slow
>> pace of "global" change that implies.
>>
>> Thanks,
>> Johann
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793