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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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"),
> > [EMAIL PROTECTED], .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]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
