Seth Falcon wrote:
>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.
>
>
Yes, as is said frequently of a certain other language "There's more
than one way to do it"
My own feeling is that class unions are a convenient shorthand & clearer
than explicitly defining the superclass and then having to establish the
inheritance separately for the two subclasses. Although the
documentation mentions that they _must_ be used for classes you don't
own, that's not their only purpose.
Virtual classes (ahem, I assume that's what you meant by "abstract"
;-)) may or may not have slots of their own. Creating a virtual class
"analyticConvolution" and doing two setIs() calls would in fact be
roughly equivalent to the setClassUnion, but not as clear, IMO.
If the superclass was really crucial to the model, that would make it
more natural to have it explicitly in the contains= for the individual
subclasses. Here, though, it seems more like a computational
convenience for a fairly small part of the overall package, so isolating
it in a single setClassUnion() call seems more natural.
Obviously, a question of taste and style.
>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
>
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
