Re: [Rd] setIs and method dispatch in S4 classes

From: Seth Falcon <sfalcon_at_fhcrc.org>
Date: Mon 10 Apr 2006 - 15:10:08 GMT

Hi John,

I found your comments helpful, even though this isn't _my_ question. But now I have one of my own :-)

John Chambers <jmc@r-project.org> writes:
>>Of course, I could also declare explicitly "+" methods for signatures
>>c("Exp", "Exp"), c("Exp", "Gammad"), and c("Gammad", "Exp") in
>>which I would then use as(.) to coerce "Exp" to "Gammad"
>> (and again the same procedure for further Gamma-methods).
>>
>>But, this would create an extra (3 or possibly much more) methods
>>to dispatch, and I doubt whether this really is the preferred
>>solution.
>>
>>
> Why not? And you can avoid some of the extra methods by defining a
> virtual class that is the union of the classes for which you want the
> new methods.
>
> Something like (untested code!)
>
> setClassUnion("analyticConvolution", c("Exp", "Gammad"))
> setMethod("+", c("analyticConvolution", "analyticConvolution"),
> ....)

Why class union here and not an abstract superclass?

If you "own" the Exp and Gammad classes, would an abstract superclass work as well? I think so.

However, if you don't own the Exp and Gammad classes, I can see that the class union approach allows you the flexibility of defining a superclass post-hoc.

I guess I have the sense that class unions are fancy/tricky (a number of popular languages don't have that concept, AFAIK). That isn't a reason not to use them in a langauge that does support them, of course.

It is an interesting design question. On the one hand, one could argue for abstract superclasses when possible because they are "less tricky" (and you need them when you want to share slots). On the other hand, the class union approach provides a more loosely coupled design since members of the union don't have to know about each other.

Hmm, I think I understand class unions a lot better already. Thanks. If I'm terribly off-track, please let me know.

+ seth



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Apr 11 01:37:25 2006

This archive was generated by hypermail 2.1.8 : Mon 10 Apr 2006 - 20:17:14 GMT