Re: [Rd] yet another problem with S4 dispatch (with setClassUnion)

From: Peter Ruckdeschel <Peter.Ruckdeschel_at_uni-bayreuth.de>
Date: Thu 13 Apr 2006 - 02:03:11 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1  

Dear John,

sorry for having bothered you with these problems.

> As I think Seth told you before, if you want to control the order
> of inheritance at the same level, you need to use the intended order
> in the contains= argument to setClass.

Apologies, but I did not catch this from Seth's mail; in fact Seth wrote

>> With the contains arg, the order determines the precedence for method
lookup.

sorry for coming up again with the same question.

> In your example (retaining the class union, although it's not required,
the superclass
> could just be an ordinary virtual class),
>
> setClassUnion("C01OrC02")
> ## C00 mother class to C01 and C02
> setClass("C00", representation(a="numeric"), prototype =c(a=0))
> setClass("C01", representation(a="numeric",b="numeric"),
> contains= c("C01OrC02", "C00"))
> setClass("C02", representation(a="numeric",d="numeric"),
> contains= c("C01OrC02", "C00"))
>
> seems to give what you want

Yes, it does. Thank you very much. Problem solved!

... and I have learned something ....

Besides the importance of order in the 'contains'-arg, beforehand, I had also somehow misunderstood the purpose of setClassUnion():
I had thought setClassUnion() was to circumvene the modification of classes (not "owned" by me); thus it was not obvious to me to write a class defined by setClassUnion() into the 'contains'-argument.

BTW: Is there a way to solve my problem without modifying the 'contains'-arguments ---
e.g. if I do not "own" classes C01, C00, C02? (This is not the case for my application, but might be of general interest) .

> To answer one of your other questions, the point about inheritance
asserting
> substitutability is that you now need to be sure that
> EVERY method for C01OrC02 is preferred to a method for C00 for
> the new subclasses.

Ok. This would be the case in my application.

> As a general design point, having these competing superclasses is likely to
> confuse the user, if not the implementer.
> If you could, it would make a clearer picture to have, e.g., C01orC02 be a
> subclass of C00.
> Then the inheritance is obvious--C01or... is a parent, while C00 is a
grandparent.
> The special contains= then doesn't need to be repeated for every
subclass Cx.

Good point; I fixed this in our package. Probably it is also a good idea then not to export this artificial (but no longer VIRTUAL) intermediate class in the NAMESPACE file.

Thank you once again, you helped us a lot. Peter

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 

iD8DBQFEPbFex+/gN8KI3u0RAgE8AJ9/M6Q7F8ldGDLVjRCCXW6PdidJRwCfW2zd rFlFbzuL4jbrav//lmrO2rE=
=iIbA
-----END PGP SIGNATURE-----



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu Apr 13 18:32:29 2006

This archive was generated by hypermail 2.1.8 : Thu 13 Apr 2006 - 10:17:04 GMT