Hi,

I am having a similar issue as reported by Paul, but I don't think Martin's
example is precisely representative of the problem.

Consider a hierarchy A <- B <- C:

> setClass("A")
[1] "A"
> setClass("B", contains="A")
[1] "B"
> setClass("C", contains="B")
[1] "C"

Now define a coerce method:

> setAs("A", "list", function(from) list())
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"

Coercing an instance "B" to a list works fine:
> as(new("B"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="B", to="list"
    (inherited from: from="A", to="list")

But note the coerce method has now been cached. It seems though that a
cached "inherited" B->list coerce method is given equal priority to the
original A->list coerce method during method selection for coercing C->list:

> as(new("C"), "list")
list()
Warning message:
Ambiguous method selection for "coerce", target "C#list" (the first of the
signatures shown will be used)
    B#list
    A#list

And so we have an ambiguity. Is this by design? Note that coercing (and thus
caching) C->list first, avoids this problem:

> setAs("A", "list", function(from) list())
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
> as(new("C"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="C", to="list"
    (inherited from: from="A", to="list")

> as(new("B"), "list")
list()
> showMethods("coerce", classes="list")
Function: coerce (package methods)
from="A", to="list"
from="ANY", to="list"
from="B", to="list"
    (inherited from: from="A", to="list")
from="C", to="list"
    (inherited from: from="A", to="list")

> as(new("C"), "list")
list()

Thanks,
Michael

On Wed, Aug 27, 2008 at 7:46 AM, Martin Morgan <mtmorgan@fhcrc.org> wrote:

> Hi Paul -- does this make the problem more explicit?
>
> > ## class hierarchy
> > setClass("A", representation=representation(a="numeric"))
> [1] "A"
> > setClass("B", representation=representation(b="numeric"))
> [1] "B"
> > setClass("C", contains=c("A", "B"))
> [1] "C"
>
> > ## coerce methods -- in some instances implicitly created
> > setAs("A", "numeric", function(from) slot(from, "a"))
> > setAs("B", "numeric", function(from) slot(from, "b"))
>
> > ## trouble: C equidistant from A, B so no unambiguous nearest 'coerce'
> > ## method
> > as(new("C"), "numeric")
> numeric(0)
> Warning message:
> Ambiguous method selection for "coerce", target "C#numeric" (the first
> of the signatures shown will be used)
>     A#numeric
>    B#numeric
>
> The solution is to define a method to resolve the conflict, e.g.,
>
> setAs("C", "numeric", function(from) {
>    ## avoid breaking the class abstraction
>    as(as(from, "A"), "numeric") *
>            as(as(from, "B"), "numeric")
> })
>
> I don't know how you want to break your particular tie; that has to do
> with the classes you're extending.
>
> Martin
>
> Paul Gilbert <pgilbert@bank-banque-canada.ca> writes:
>
> > I am extending a DBI connection by
> >
> > setClass("TSPostgreSQLConnection",
> > contains=c("PostgreSQLConnection","TSdbOptions"))
> >
> > but the first time I use this I am getting a warning when it tries to
> > coerce  the  TSPostgreSQLConnection to a PostgreSQLConnection. After
> > the first use the warning stops,  but the first warning is causing me
> > problems when I do automatic checks and set my tests to stop on
> > warnings. (I think there should be a correct way to do this that does
> > not produce a warning.)  I can trace it back by setting
> > options(warn=2) as below.  Do I need to be more specific about how the
> > coercion  happens? If so, what is the correct way to coerce the
> > TSPostgreSQLConnection into a PostgreSQLConnection? If not, how to a
> > get rid of the warning?
> >
> > Paul Gilbert
> >
> >
> >  > TSdelete("vec", con)
> > Error: (converted from warning) Ambiguous method selection for
> > "coerce", target "TSPostgreSQLConnection#integer" (the first of the
> > signatures shown will be used)
> >    PostgreSQLConnection#integer
> >    dbObjectId#integer
> >  > traceback()
> > 15: doWithOneRestart(return(expr), restart)
> > 14: withOneRestart(expr, restarts[[1]])
> > 13: withRestarts({
> >        .Internal(.signalCondition(simpleWarning(msg, call), msg,
> >            call))
> >        .Internal(.dfltWarn(msg, call))
> >    }, muffleWarning = function() NULL)
> > 12: .signalSimpleWarning("Ambiguous method selection for \"coerce\",
> > target \"TSPostgreSQLConnection#integer\" (the first of the signatures
> > shown will be used)\n    PostgreSQLConnection#integer\n
> > dbObjectId#integer\n",
> >        quote(NULL))
> > 11: warning(gettextf(paste("Ambiguous method selection for \"%s\",
> > target \"%s\"",
> >        "(the first of the signatures shown will be used)\n%s\n"),
> >        fdef@generic, .sigLabel(classes), paste("   ", names(methods),
> >            collapse = "\n")), domain = NA, call. = FALSE)
> > 10: .findInheritedMethods(signature, fdef, mtable = allmethods, table
> > = mlist,
> >        useInherited = useInherited, verbose = verbose)
> > 9: selectMethod("coerce", sig, optional = TRUE, c(from = TRUE, to =
> FALSE),
> >       fdef = coerceFun, mlist = coerceMethods)
> > 8: as(obj, "integer")
> > 7: isIdCurrent(con)
> > 6: postgresqlQuickSQL(conn, statement, ...)
> > 5: dbGetQuery(con, paste("SELECT tbl  FROM Meta ", where, ";"))
> > 4: dbGetQuery(con, paste("SELECT tbl  FROM Meta ", where, ";"))
> > 3: TSdbi:::TSdeleteSQL(serIDs = serIDs, con = con, ...)
> > 2: TSdelete("vec", con)
> > 1: TSdelete("vec", con)
> >  >  str(con)
> > Formal class 'TSPostgreSQLConnection' [package "TSPostgreSQL"] with 4
> slots
> >  ..@ Id     : int [1:2] 21795 1
> >  ..@ dbname : chr "test"
> >  ..@ vintage: logi FALSE
> >  ..@ panel  : logi FALSE
> >
> ====================================================================================
> >
> > La version française suit le texte anglais.
> >
> >
> ------------------------------------------------------------------------------------
> >
> > This email may contain privileged and/or confidential in...{{dropped:26}}
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Martin Morgan
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M2 B169
> Phone: (206) 667-2793
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]

