The problem is not with setting up the union, but with updating the cached
version of the subclasses that are implicitly members of the union.
Think of it this way. Class "B" does not have a superclass "C" in its
incarnation on PkgB. Only dynamically in the situation you have created does
this become a superclass whose methods are intended to be available.
Similarly, class "A" does not have "B" as a subclass until PkgB is loaded.
The "error" is not in defining the union class but (if my guesses were correct)
in that the cached version of classes "A" and "B" were not updated when new
packages were loaded.
In the more realistic case that "C" is on yet another package, this has to
happen when PkgC is loaded.
As I said, the dynamic nature of R makes for these problems (but is also one of
the language's important assets).
John
On May 8, 2013, at 10:46 PM, Renaud Gaujoux <ren...@mancala.cbio.uct.ac.za>
wrote:
> I obviously cannot predict the implications as much as John, but would the
> followings be solutions:
>
> - setClassUnion looks up for subclasses of its elements and add them up, and
> setClass('A', ...) would update the union classes of any superclass of 'A'.
> removeClass would need to do some cleanup, which it probably does already.
> - OR, extends(class1) could lookup at runtime for union classes that include
> a superclass of class1. Caching on class1 could be used, reset by any
> subsequent call to setClass(class1, ...) or removeClass(class1). I guess
> setClassUnion would also do the same to deal with union of unions.
>
> Renaud
>
>
> On 8 May 2013 19:02, John Chambers <j...@r-project.org> wrote:
> No need for generic functions and methods. Just looking at the hierarchy of
> the classes shows the problem.
>
> With Martin's simplified version:
>
> > library(PkgA)
> > extends("A")
> [1] "A"
> > library(PkgB)
> > extends("B")
> [1] "B" "A"
>
> > setClassUnion("C", c("matrix", "A"))
> > extends("A")
> [1] "A" "C"
> > extends("B")
> [1] "B" "A"
>
>
> So defining the union does not make all the subclasses of "A" members of the
> union.
>
> The next comments are guesses but plausible. Loading the namespace of PkgB
> may not update the known subclasses of classes from PkgA.
>
> This is one of R's touchier points in general: The state of things with
> respect to classes and methods changes dynamically as packages are loaded.
> Until PkgB is loaded, "A" has no known subclasses.
>
> If the guess is correct, then when the class union is formed, nothing tells
> us that "A" has a subclass "B" that should be added to the union.
>
> Fixing this properly may involve the load-time actions and not be quite
> trivial.
>
> John
>
>
>
> On 5/7/13 11:05 PM, Renaud Gaujoux wrote:
> Hi,
>
> I started this post on bioc-devel but this seems to be more general:
>
> https://stat.ethz.ch/pipermail/bioc-devel/2013-May/004311.html
>
> See reproducible example from Martin below.
>
> Thank you.
>
> Renaud
>
> ---------- Forwarded message ----------
> From: Martin Morgan <mtmor...@fhcrc.org>
> Date: 7 May 2013 19:55
> Subject: Re: [Bioc-devel] ExpressionSet and LumiBatch: inheritance problem
> in S4 methods for union class
> To: Renaud Gaujoux <ren...@mancala.cbio.uct.ac.za>
> Cc: bioc-de...@r-project.org, dupan.m...@gmail.com
>
> I can replicate this with a simpler example, where PkgA has
>
> setClass("A", representation(x="numeric"))
>
> with NAMESPACE
>
> import(methods)
> exportClasses("A")
>
> PkgB has
>
> setClass("B", contains="A")
>
> NAMESPACE
>
> import(methods)
> importClassesFrom("PkgA", "A")
> exportClasses("B")
>
> and then
>
> library(PkgA); library(PkgB)
> setClassUnion("C", c("matrix", "A"))
> setGeneric("do", function(x) standardGeneric("do"))
> setMethod("do", "C", function(x) "done")
>
> leading to
>
> > do(new("A"))
> [1] "done"
> > do(new("B"))
>
> Error in (function (classes, fdef, mtable) :
> unable to find an inherited method for function do for signature "B"
>
> suggesting name space issues rather than something about ExpressionSet. The
> sample packages and test script are attached; it would be appropriate to
> pursue this on the R-devel mailing list.
>
> Martin
>
>
>
> ______________________________________________
> 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
