[Rd] setGeneric for residuals, etc

[Kasper Daniel Hansen]

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.
>
> 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
>