Hi John,
I found your comments helpful, even though this isn't _my_ question.
But now I have one of my own :-)
John Chambers <[EMAIL PROTECTED]> 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
