RC / methods package

[Paul Gilbert-2]

(I think this is being caused by the new methods package in RC.)

In the RC (March 24) some of my packages are generating a Note

Note: Method with signature "MySQLConnection#integer" chosen for
function "coerce",
  target signature "TSMySQLConnection#integer".
  "dbObjectId#integer" would also be valid

This is coming from a call to dbGetQuery() in package DBI. The method
with the signature "TSMySQLConnection#integer" is generated
automatically because TSMySQLConnection inherits from
MySQLConnection. (More details below.)

Is there a way to pass this information along to coerce when the method
is generated, or otherwise suppress the Note?

BTW,
  1/ It would be nice if the Note mentioned what method is generating
it, in addition to the signature. Debugging for a call several levels
deep in the stack is already hard enough.

  2/ The note only seems to get generated on the first call and then
gets suppressed. This will be nice for users, but makes debugging
harder. Is there a way to prevent suppressing the message?

  3/ It seems strange that  getMethod() cannot find the methods even
though showMethods() shows it. (See below.)

Paul
________

 >showMethods("dbGetQuery")
Function: dbGetQuery (package DBI)
conn="MySQLConnection", statement="character"

 >   z <- TSget("Series 1", con, TSrepresentation="timeSeries")
Note: Method with signature "MySQLConnection#integer" chosen for
function "coerce",
  target signature "TSMySQLConnection#integer".
  "dbObjectId#integer" would also be valid
Loading required package: zoo

Attaching package: ‘zoo’

The following object(s) are masked from ‘package:timeSeries’:

     time<-

The following object(s) are masked from ‘package:base’:

     as.Date, as.Date.numeric

 >  showMethods("dbGetQuery")
Function: dbGetQuery (package DBI)
conn="MySQLConnection", statement="character"
conn="TSMySQLConnection", statement="character"
     (inherited from: conn="MySQLConnection", statement="character")

 > getMethod("dbGetQuery",  signature = c("TSMySQLConnection",
statement="character"))
Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
statement = "character")) :
   No method found for function "dbGetQuery" and signature
TSMySQLConnection, character
 >

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[John Chambers-2]

On 3/24/12 1:29 PM, Paul Gilbert wrote:
> (I think this is being caused by the new methods package in RC.)
Possibly, but the methods package isn't particularly "new" in its method
selection.

We need to see the definition of the class.  The note implies that it
inherits from both "MySQLConnection" and "dbObjectId", both of which
have methods for coercing to "integer".  Hence the ambiguity.

>
> In the RC (March 24) some of my packages are generating a Note
>
> Note: Method with signature "MySQLConnection#integer" chosen for
> function "coerce",
>  target signature "TSMySQLConnection#integer".
>  "dbObjectId#integer" would also be valid
>
> This is coming from a call to dbGetQuery() in package DBI. The method
> with the signature "TSMySQLConnection#integer" is generated
> automatically because TSMySQLConnection inherits from
> MySQLConnection. (More details below.)
>
> Is there a way to pass this information along to coerce when the
> method is generated, or otherwise suppress the Note?

No.  Methods are inherited according to rules implied by the class
inheritance; R doesn't allow you to override the inheritance, other than
by being more explicit about the method definition.  (It's only a note,
and IMO a relevant one.  Be glad the language isn't Dylan, which treats
similar ambiguities as a programming error. :-))
>
> BTW,
>  1/ It would be nice if the Note mentioned what method is generating
> it, in addition to the signature. Debugging for a call several levels
> deep in the stack is already hard enough.
?? it does, for coerce()  which admittedly you have to know is the
method defined for as(thing, "integer") either directly or indirectly.  
Unless you mean showing you the whole method definition, but that seems
not relevant to selection.

If you wanted to see the coerce() method, you need to do
showMethods("coerce"), but I don't think that's relevant.  As mentioned,
it's the class hierarchy that matters.
>
>  2/ The note only seems to get generated on the first call and then
> gets suppressed. This will be nice for users, but makes debugging
> harder. Is there a way to prevent suppressing the message?
No.  the note is generated when an inherited method is found.  That
method is then cached, so the computations required are (fortunately)
not repeated.

It would be nice to have tools that the package writer could apply to
generate all possible inheritance patterns, and flag possible
ambiguities at package INSTALL time, as opposed to when the package is
used.  But it's likely that would generate so many cases unlikely to
occur that the package developer would ignore it, even assuming the
developer was energetic enough to use the tool in the first place.
> o
>  3/ It seems strange that  getMethod() cannot find the methods even
> though showMethods() shows it. (See below.)
I think you're confusing getMethod(), which only finds directly defined
methods, with selectMethod() which replicates the inheritance computations.

In any case the selection of the method has been specified for you already.

John

>
> Paul
> ________
>
> >showMethods("dbGetQuery")
> Function: dbGetQuery (package DBI)
> conn="MySQLConnection", statement="character"
>
> >   z <- TSget("Series 1", con, TSrepresentation="timeSeries")
> Note: Method with signature "MySQLConnection#integer" chosen for
> function "coerce",
>  target signature "TSMySQLConnection#integer".
>  "dbObjectId#integer" would also be valid
> Loading required package: zoo
>
> Attaching package: ‘zoo’
>
> The following object(s) are masked from ‘package:timeSeries’:
>
>     time<-
>
> The following object(s) are masked from ‘package:base’:
>
>     as.Date, as.Date.numeric
>
> >  showMethods("dbGetQuery")
> Function: dbGetQuery (package DBI)
> conn="MySQLConnection", statement="character"
> conn="TSMySQLConnection", statement="character"
>     (inherited from: conn="MySQLConnection", statement="character")
>
> > getMethod("dbGetQuery",  signature = c("TSMySQLConnection",
> statement="character"))
> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
> statement = "character")) :
>   No method found for function "dbGetQuery" and signature
> TSMySQLConnection, character
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[John Chambers-2]

On 3/24/12 5:43 PM, Paul Gilbert wrote:

>
>
> On 12-03-24 08:11 PM, John Chambers wrote:
>>
>>
>> On 3/24/12 1:29 PM, Paul Gilbert wrote:
>>> (I think this is being caused by the new methods package in RC.)
>> Possibly, but the methods package isn't particularly "new" in its method
>> selection.
>>
>> We need to see the definition of the class.
>
> Is there a way to know which class it is that we need to see the
> definition for?

It's in the note:  'target signature "TSMySQLConnection#integer"'.  In
functional OOP with multiple dispatch, it's all the classes that matter
in general, but in this and most cases, one class is likely the relevant
one:  "TSMySQLConnection".  That was why I said what I did before.

(We could go to a bit more effort and back-translate the dispatch string
"TSMySQLConnection#integer" into the corresponding formal arguments.
Would be more natural with the INSTALL time tool I mentioned before.
That's the real challenge here -- to give information about this to the
package developer, not the poor user.)

John

>
> Paul
>
>> The note implies that it
>> inherits from both "MySQLConnection" and "dbObjectId", both of which
>> have methods for coercing to "integer". Hence the ambiguity.
>>>
>>> In the RC (March 24) some of my packages are generating a Note
>>>
>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>> function "coerce",
>>> target signature "TSMySQLConnection#integer".
>>> "dbObjectId#integer" would also be valid
>>>
>>> This is coming from a call to dbGetQuery() in package DBI. The method
>>> with the signature "TSMySQLConnection#integer" is generated
>>> automatically because TSMySQLConnection inherits from
>>> MySQLConnection. (More details below.)
>>>
>>> Is there a way to pass this information along to coerce when the
>>> method is generated, or otherwise suppress the Note?
>> No. Methods are inherited according to rules implied by the class
>> inheritance; R doesn't allow you to override the inheritance, other than
>> by being more explicit about the method definition. (It's only a note,
>> and IMO a relevant one. Be glad the language isn't Dylan, which treats
>> similar ambiguities as a programming error. :-))
>>>
>>> BTW,
>>> 1/ It would be nice if the Note mentioned what method is generating
>>> it, in addition to the signature. Debugging for a call several levels
>>> deep in the stack is already hard enough.
>> ?? it does, for coerce() which admittedly you have to know is the method
>> defined for as(thing, "integer") either directly or indirectly. Unless
>> you mean showing you the whole method definition, but that seems not
>> relevant to selection.
>>
>> If you wanted to see the coerce() method, you need to do
>> showMethods("coerce"), but I don't think that's relevant. As mentioned,
>> it's the class hierarchy that matters.
>>>
>>> 2/ The note only seems to get generated on the first call and then
>>> gets suppressed. This will be nice for users, but makes debugging
>>> harder. Is there a way to prevent suppressing the message?
>> No. the note is generated when an inherited method is found. That method
>> is then cached, so the computations required are (fortunately) not
>> repeated.
>>
>> It would be nice to have tools that the package writer could apply to
>> generate all possible inheritance patterns, and flag possible
>> ambiguities at package INSTALL time, as opposed to when the package is
>> used. But it's likely that would generate so many cases unlikely to
>> occur that the package developer would ignore it, even assuming the
>> developer was energetic enough to use the tool in the first place.
>>> o
>>> 3/ It seems strange that getMethod() cannot find the methods even
>>> though showMethods() shows it. (See below.)
>> I think you're confusing getMethod(), which only finds directly defined
>> methods, with selectMethod() which replicates the inheritance
>> computations.
>>
>> In any case the selection of the method has been specified for you
>> already.
>>
>> John
>>>
>>> Paul
>>> ________
>>>
>>> >showMethods("dbGetQuery")
>>> Function: dbGetQuery (package DBI)
>>> conn="MySQLConnection", statement="character"
>>>
>>> > z <- TSget("Series 1", con, TSrepresentation="timeSeries")
>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>> function "coerce",
>>> target signature "TSMySQLConnection#integer".
>>> "dbObjectId#integer" would also be valid
>>> Loading required package: zoo
>>>
>>> Attaching package: ‘zoo’
>>>
>>> The following object(s) are masked from ‘package:timeSeries’:
>>>
>>> time<-
>>>
>>> The following object(s) are masked from ‘package:base’:
>>>
>>> as.Date, as.Date.numeric
>>>
>>> > showMethods("dbGetQuery")
>>> Function: dbGetQuery (package DBI)
>>> conn="MySQLConnection", statement="character"
>>> conn="TSMySQLConnection", statement="character"
>>> (inherited from: conn="MySQLConnection", statement="character")
>>>
>>> > getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>> statement="character"))
>>> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>> statement = "character")) :
>>> No method found for function "dbGetQuery" and signature
>>> TSMySQLConnection, character
>>> >
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Paul Gilbert-2]

John

Here is the definition of the TSMySQLConnection class, and a few other
things. This is a simplified example that produces the message, but
unfortunately will not work unless you have a MySQL database to connect
to. (I do get the same problem with PostgreSQL, and may with SQLLite,
but I have not tested the last yet.)

require("methods")
require("DBI")
require("RMySQL")

setClassUnion("OptionalPOSIXct",   c("POSIXct",   "logical"))
setClass("conType", representation( drv="character"), "VIRTUAL" )

setClass("TSdb", representation( dbname="character",
     hasVintages="logical", hasPanels="logical"), "VIRTUAL" )


setClass("TSMySQLConnection", contains=c("MySQLConnection", "conType",
"TSdb"))


setGeneric("TSconnect", def= function(drv, dbname, ...)
standardGeneric("TSconnect"))


setMethod("TSconnect",   signature(drv="MySQLDriver", dbname="character"),
    definition=function(drv, dbname, ...) {
         con <- dbConnect(drv, dbname=dbname, ...)
        new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
          hasVintages=dbExistsTable(con, "vintageAlias"),
          hasPanels  =dbExistsTable(con, "panels"))
        })

con <- TSconnect(dbDriver("MySQL"), "test")

dbGetQuery(con, "show tables")
Note: Method with signature "MySQLConnection#integer" chosen for
function "coerce",
  target signature "TSMySQLConnection#integer".
  "dbObjectId#integer" would also be valid
    Tables_in_test
1               A
2               B
 >

The message also seems to go away, even quitting R and restarting to
clear the cache, if I change the TSconnect method as follow

setMethod("TSconnect",   signature(drv="MySQLDriver", dbname="character"),
    definition=function(drv, dbname, ...) {
         con <- dbConnect(drv, dbname=dbname, ...)
        new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
          hasVintages=FALSE,
          hasPanels  =FALSE)
        })

Why this would happen makes absolutely no sense to me. In the first
version is  dbExistsTable(con, "vintageAlias") left unevaluated in the
result from new?

As you can tell, I'm struggling a bit with interpreting the information
from the note. Also, if it were a warning I could set it to stop, and
then traceback to what was causing the problem. As it is, it took me a
fairly long time just to get the fact that the call to dbGetQuery() was
generating the message. And caching the methods may be good for
performance, but when things change the second time you call them it
sure makes debugging difficult.

Best,
Paul


On 12-03-25 03:24 PM, John Chambers wrote:

> On 3/24/12 5:43 PM, Paul Gilbert wrote:
>>
>>
>> On 12-03-24 08:11 PM, John Chambers wrote:
>>>
>>>
>>> On 3/24/12 1:29 PM, Paul Gilbert wrote:
>>>> (I think this is being caused by the new methods package in RC.)
>>> Possibly, but the methods package isn't particularly "new" in its method
>>> selection.
>>>
>>> We need to see the definition of the class.
>>
>> Is there a way to know which class it is that we need to see the
>> definition for?
>
> It's in the note: 'target signature "TSMySQLConnection#integer"'. In
> functional OOP with multiple dispatch, it's all the classes that matter
> in general, but in this and most cases, one class is likely the relevant
> one: "TSMySQLConnection". That was why I said what I did before.
>
> (We could go to a bit more effort and back-translate the dispatch string
> "TSMySQLConnection#integer" into the corresponding formal arguments.
> Would be more natural with the INSTALL time tool I mentioned before.
> That's the real challenge here -- to give information about this to the
> package developer, not the poor user.)
>
> John
>
>>
>> Paul
>>
>>> The note implies that it
>>> inherits from both "MySQLConnection" and "dbObjectId", both of which
>>> have methods for coercing to "integer". Hence the ambiguity.
>>>>
>>>> In the RC (March 24) some of my packages are generating a Note
>>>>
>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>> function "coerce",
>>>> target signature "TSMySQLConnection#integer".
>>>> "dbObjectId#integer" would also be valid
>>>>
>>>> This is coming from a call to dbGetQuery() in package DBI. The method
>>>> with the signature "TSMySQLConnection#integer" is generated
>>>> automatically because TSMySQLConnection inherits from
>>>> MySQLConnection. (More details below.)
>>>>
>>>> Is there a way to pass this information along to coerce when the
>>>> method is generated, or otherwise suppress the Note?
>>> No. Methods are inherited according to rules implied by the class
>>> inheritance; R doesn't allow you to override the inheritance, other than
>>> by being more explicit about the method definition. (It's only a note,
>>> and IMO a relevant one. Be glad the language isn't Dylan, which treats
>>> similar ambiguities as a programming error. :-))
>>>>
>>>> BTW,
>>>> 1/ It would be nice if the Note mentioned what method is generating
>>>> it, in addition to the signature. Debugging for a call several levels
>>>> deep in the stack is already hard enough.
>>> ?? it does, for coerce() which admittedly you have to know is the method
>>> defined for as(thing, "integer") either directly or indirectly. Unless
>>> you mean showing you the whole method definition, but that seems not
>>> relevant to selection.
>>>
>>> If you wanted to see the coerce() method, you need to do
>>> showMethods("coerce"), but I don't think that's relevant. As mentioned,
>>> it's the class hierarchy that matters.
>>>>
>>>> 2/ The note only seems to get generated on the first call and then
>>>> gets suppressed. This will be nice for users, but makes debugging
>>>> harder. Is there a way to prevent suppressing the message?
>>> No. the note is generated when an inherited method is found. That method
>>> is then cached, so the computations required are (fortunately) not
>>> repeated.
>>>
>>> It would be nice to have tools that the package writer could apply to
>>> generate all possible inheritance patterns, and flag possible
>>> ambiguities at package INSTALL time, as opposed to when the package is
>>> used. But it's likely that would generate so many cases unlikely to
>>> occur that the package developer would ignore it, even assuming the
>>> developer was energetic enough to use the tool in the first place.
>>>> o
>>>> 3/ It seems strange that getMethod() cannot find the methods even
>>>> though showMethods() shows it. (See below.)
>>> I think you're confusing getMethod(), which only finds directly defined
>>> methods, with selectMethod() which replicates the inheritance
>>> computations.
>>>
>>> In any case the selection of the method has been specified for you
>>> already.
>>>
>>> John
>>>>
>>>> Paul
>>>> ________
>>>>
>>>> >showMethods("dbGetQuery")
>>>> Function: dbGetQuery (package DBI)
>>>> conn="MySQLConnection", statement="character"
>>>>
>>>> > z <- TSget("Series 1", con, TSrepresentation="timeSeries")
>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>> function "coerce",
>>>> target signature "TSMySQLConnection#integer".
>>>> "dbObjectId#integer" would also be valid
>>>> Loading required package: zoo
>>>>
>>>> Attaching package: ‘zoo’
>>>>
>>>> The following object(s) are masked from ‘package:timeSeries’:
>>>>
>>>> time<-
>>>>
>>>> The following object(s) are masked from ‘package:base’:
>>>>
>>>> as.Date, as.Date.numeric
>>>>
>>>> > showMethods("dbGetQuery")
>>>> Function: dbGetQuery (package DBI)
>>>> conn="MySQLConnection", statement="character"
>>>> conn="TSMySQLConnection", statement="character"
>>>> (inherited from: conn="MySQLConnection", statement="character")
>>>>
>>>> > getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>> statement="character"))
>>>> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>> statement = "character")) :
>>>> No method found for function "dbGetQuery" and signature
>>>> TSMySQLConnection, character
>>>> >
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Paul Gilbert-2]

On 12-03-25 05:29 PM, Paul Gilbert wrote:

> John
>
> Here is the definition of the TSMySQLConnection class, and a few other
> things. This is a simplified example that produces the message, but
> unfortunately will not work unless you have a MySQL database to connect
> to. (I do get the same problem with PostgreSQL, and may with SQLLite,
> but I have not tested the last yet.)
>
> require("methods")
> require("DBI")
> require("RMySQL")
>
> setClassUnion("OptionalPOSIXct", c("POSIXct", "logical"))
> setClass("conType", representation( drv="character"), "VIRTUAL" )
>
> setClass("TSdb", representation( dbname="character",
> hasVintages="logical", hasPanels="logical"), "VIRTUAL" )
>
>
> setClass("TSMySQLConnection", contains=c("MySQLConnection", "conType",
> "TSdb"))
>
>
> setGeneric("TSconnect", def= function(drv, dbname, ...)
> standardGeneric("TSconnect"))
>
>
> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
> definition=function(drv, dbname, ...) {
> con <- dbConnect(drv, dbname=dbname, ...)
> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
> hasVintages=dbExistsTable(con, "vintageAlias"),
> hasPanels =dbExistsTable(con, "panels"))
> })
>
> con <- TSconnect(dbDriver("MySQL"), "test")
>
> dbGetQuery(con, "show tables")
> Note: Method with signature "MySQLConnection#integer" chosen for
> function "coerce",
> target signature "TSMySQLConnection#integer".
> "dbObjectId#integer" would also be valid
> Tables_in_test
> 1 A
> 2 B
>  >
>
> The message also seems to go away, even quitting R and restarting to
> clear the cache, if I change the TSconnect method as follow
>
> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
> definition=function(drv, dbname, ...) {
> con <- dbConnect(drv, dbname=dbname, ...)
> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
> hasVintages=FALSE,
> hasPanels =FALSE)
> })
>
> Why this would happen makes absolutely no sense to me. In the first
> version is dbExistsTable(con, "vintageAlias") left unevaluated in the
> result from new?

This is very strange. With

setMethod("TSconnect",   signature(drv="MySQLDriver", dbname="character"),
    definition=function(drv, dbname, ...) {
         con <- dbConnect(drv, dbname=dbname, ...)
    hasVintages <- as.logical(dbExistsTable(con, "vintageAlias") )
    hasPanels   <- as.logical(dbExistsTable(con, "panels") )
        new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
          hasVintages=FALSE,
          hasPanels  =FALSE)
        })

I get the note, but if I remove the two lines that appear to do nothing:

setMethod("TSconnect",   signature(drv="MySQLDriver", dbname="character"),
    definition=function(drv, dbname, ...) {
         con <- dbConnect(drv, dbname=dbname, ...)
        new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
          hasVintages=FALSE,
          hasPanels  =FALSE)
        })

I no longer get the note. I am restarting R each time to be sure nothing
is cached.

[ R version 2.15.0 RC (2012-03-25 r58832) ]

Paul

>
> As you can tell, I'm struggling a bit with interpreting the information
> from the note. Also, if it were a warning I could set it to stop, and
> then traceback to what was causing the problem. As it is, it took me a
> fairly long time just to get the fact that the call to dbGetQuery() was
> generating the message. And caching the methods may be good for
> performance, but when things change the second time you call them it
> sure makes debugging difficult.
>
> Best,
> Paul
>
>
> On 12-03-25 03:24 PM, John Chambers wrote:
>> On 3/24/12 5:43 PM, Paul Gilbert wrote:
>>>
>>>
>>> On 12-03-24 08:11 PM, John Chambers wrote:
>>>>
>>>>
>>>> On 3/24/12 1:29 PM, Paul Gilbert wrote:
>>>>> (I think this is being caused by the new methods package in RC.)
>>>> Possibly, but the methods package isn't particularly "new" in its
>>>> method
>>>> selection.
>>>>
>>>> We need to see the definition of the class.
>>>
>>> Is there a way to know which class it is that we need to see the
>>> definition for?
>>
>> It's in the note: 'target signature "TSMySQLConnection#integer"'. In
>> functional OOP with multiple dispatch, it's all the classes that matter
>> in general, but in this and most cases, one class is likely the relevant
>> one: "TSMySQLConnection". That was why I said what I did before.
>>
>> (We could go to a bit more effort and back-translate the dispatch string
>> "TSMySQLConnection#integer" into the corresponding formal arguments.
>> Would be more natural with the INSTALL time tool I mentioned before.
>> That's the real challenge here -- to give information about this to the
>> package developer, not the poor user.)
>>
>> John
>>
>>>
>>> Paul
>>>
>>>> The note implies that it
>>>> inherits from both "MySQLConnection" and "dbObjectId", both of which
>>>> have methods for coercing to "integer". Hence the ambiguity.
>>>>>
>>>>> In the RC (March 24) some of my packages are generating a Note
>>>>>
>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>> function "coerce",
>>>>> target signature "TSMySQLConnection#integer".
>>>>> "dbObjectId#integer" would also be valid
>>>>>
>>>>> This is coming from a call to dbGetQuery() in package DBI. The method
>>>>> with the signature "TSMySQLConnection#integer" is generated
>>>>> automatically because TSMySQLConnection inherits from
>>>>> MySQLConnection. (More details below.)
>>>>>
>>>>> Is there a way to pass this information along to coerce when the
>>>>> method is generated, or otherwise suppress the Note?
>>>> No. Methods are inherited according to rules implied by the class
>>>> inheritance; R doesn't allow you to override the inheritance, other
>>>> than
>>>> by being more explicit about the method definition. (It's only a note,
>>>> and IMO a relevant one. Be glad the language isn't Dylan, which treats
>>>> similar ambiguities as a programming error. :-))
>>>>>
>>>>> BTW,
>>>>> 1/ It would be nice if the Note mentioned what method is generating
>>>>> it, in addition to the signature. Debugging for a call several levels
>>>>> deep in the stack is already hard enough.
>>>> ?? it does, for coerce() which admittedly you have to know is the
>>>> method
>>>> defined for as(thing, "integer") either directly or indirectly. Unless
>>>> you mean showing you the whole method definition, but that seems not
>>>> relevant to selection.
>>>>
>>>> If you wanted to see the coerce() method, you need to do
>>>> showMethods("coerce"), but I don't think that's relevant. As mentioned,
>>>> it's the class hierarchy that matters.
>>>>>
>>>>> 2/ The note only seems to get generated on the first call and then
>>>>> gets suppressed. This will be nice for users, but makes debugging
>>>>> harder. Is there a way to prevent suppressing the message?
>>>> No. the note is generated when an inherited method is found. That
>>>> method
>>>> is then cached, so the computations required are (fortunately) not
>>>> repeated.
>>>>
>>>> It would be nice to have tools that the package writer could apply to
>>>> generate all possible inheritance patterns, and flag possible
>>>> ambiguities at package INSTALL time, as opposed to when the package is
>>>> used. But it's likely that would generate so many cases unlikely to
>>>> occur that the package developer would ignore it, even assuming the
>>>> developer was energetic enough to use the tool in the first place.
>>>>> o
>>>>> 3/ It seems strange that getMethod() cannot find the methods even
>>>>> though showMethods() shows it. (See below.)
>>>> I think you're confusing getMethod(), which only finds directly defined
>>>> methods, with selectMethod() which replicates the inheritance
>>>> computations.
>>>>
>>>> In any case the selection of the method has been specified for you
>>>> already.
>>>>
>>>> John
>>>>>
>>>>> Paul
>>>>> ________
>>>>>
>>>>> >showMethods("dbGetQuery")
>>>>> Function: dbGetQuery (package DBI)
>>>>> conn="MySQLConnection", statement="character"
>>>>>
>>>>> > z <- TSget("Series 1", con, TSrepresentation="timeSeries")
>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>> function "coerce",
>>>>> target signature "TSMySQLConnection#integer".
>>>>> "dbObjectId#integer" would also be valid
>>>>> Loading required package: zoo
>>>>>
>>>>> Attaching package: ‘zoo’
>>>>>
>>>>> The following object(s) are masked from ‘package:timeSeries’:
>>>>>
>>>>> time<-
>>>>>
>>>>> The following object(s) are masked from ‘package:base’:
>>>>>
>>>>> as.Date, as.Date.numeric
>>>>>
>>>>> > showMethods("dbGetQuery")
>>>>> Function: dbGetQuery (package DBI)
>>>>> conn="MySQLConnection", statement="character"
>>>>> conn="TSMySQLConnection", statement="character"
>>>>> (inherited from: conn="MySQLConnection", statement="character")
>>>>>
>>>>> > getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>> statement="character"))
>>>>> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>> statement = "character")) :
>>>>> No method found for function "dbGetQuery" and signature
>>>>> TSMySQLConnection, character
>>>>> >
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[John Chambers-2]

This direction is perhaps adding to the confusion rather than reducing it.

Let's go back to the original note:

Note: Method with signature "MySQLConnection#integer" chosen for
function "coerce",
  target signature "TSMySQLConnection#integer".
  "dbObjectId#integer" would also be valid

The purpose of the note is just to make you (the programmer) aware that
in fact two methods are available for coercing from "TSMySQLConnection"
to "integer".  Which do you want, if either?

If it's not the one from "MySQLConnection" then one needs to say
explicitly what it should be.  In any case, being explicit would remove
the note, if that's what is bothering people.

The "coerce" generic is abnormal, in that its methods are rarely
specified directly, but via a setAs() call and it's never invoked
directly, but rather from an as(thing, "integer")--this may in part be
why the behavior is confusing.

If you have an example that produces the note, the relevant methods can
be examined by following that example with
   getMethod("coerce", c("MySQLConnection","integer"))
   getMethod("coerce", c("dbObject","integer"))
You DO have to wait until the note is produced because the as()
calculations may install methods for coerce() in response to particular
calls.

Then it's likely you want to insert a
   setAs("TSMySQLConnection", "integer", ....)
into the package that defines "TSMySQLConnection", with the chosen
definition.

Just to repeat:  This is a "Note" and doesn't necessarily indicate a
bug.  It's in the nature of functional OOP with multiple dispatch that
there can be multiple eligible methods.  It may or may not matter which
is chosen, and one can't guarantee that any automatic selection will get
the "right" one.  It's nearly always helpful to be as specific as
possible where ambiguities do exist.

John

On 3/26/12 6:23 AM, Paul Gilbert wrote:

>
>
> On 12-03-25 05:29 PM, Paul Gilbert wrote:
>> John
>>
>> Here is the definition of the TSMySQLConnection class, and a few other
>> things. This is a simplified example that produces the message, but
>> unfortunately will not work unless you have a MySQL database to connect
>> to. (I do get the same problem with PostgreSQL, and may with SQLLite,
>> but I have not tested the last yet.)
>>
>> require("methods")
>> require("DBI")
>> require("RMySQL")
>>
>> setClassUnion("OptionalPOSIXct", c("POSIXct", "logical"))
>> setClass("conType", representation( drv="character"), "VIRTUAL" )
>>
>> setClass("TSdb", representation( dbname="character",
>> hasVintages="logical", hasPanels="logical"), "VIRTUAL" )
>>
>>
>> setClass("TSMySQLConnection", contains=c("MySQLConnection", "conType",
>> "TSdb"))
>>
>>
>> setGeneric("TSconnect", def= function(drv, dbname, ...)
>> standardGeneric("TSconnect"))
>>
>>
>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>> definition=function(drv, dbname, ...) {
>> con <- dbConnect(drv, dbname=dbname, ...)
>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>> hasVintages=dbExistsTable(con, "vintageAlias"),
>> hasPanels =dbExistsTable(con, "panels"))
>> })
>>
>> con <- TSconnect(dbDriver("MySQL"), "test")
>>
>> dbGetQuery(con, "show tables")
>> Note: Method with signature "MySQLConnection#integer" chosen for
>> function "coerce",
>> target signature "TSMySQLConnection#integer".
>> "dbObjectId#integer" would also be valid
>> Tables_in_test
>> 1 A
>> 2 B
>> >
>>
>> The message also seems to go away, even quitting R and restarting to
>> clear the cache, if I change the TSconnect method as follow
>>
>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>> definition=function(drv, dbname, ...) {
>> con <- dbConnect(drv, dbname=dbname, ...)
>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>> hasVintages=FALSE,
>> hasPanels =FALSE)
>> })
>>
>> Why this would happen makes absolutely no sense to me. In the first
>> version is dbExistsTable(con, "vintageAlias") left unevaluated in the
>> result from new?
>
> This is very strange. With
>
> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
> definition=function(drv, dbname, ...) {
> con <- dbConnect(drv, dbname=dbname, ...)
> hasVintages <- as.logical(dbExistsTable(con, "vintageAlias") )
> hasPanels <- as.logical(dbExistsTable(con, "panels") )
> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
> hasVintages=FALSE,
> hasPanels =FALSE)
> })
>
> I get the note, but if I remove the two lines that appear to do nothing:
>
> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
> definition=function(drv, dbname, ...) {
> con <- dbConnect(drv, dbname=dbname, ...)
> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
> hasVintages=FALSE,
> hasPanels =FALSE)
> })
>
> I no longer get the note. I am restarting R each time to be sure nothing
> is cached.
>
> [ R version 2.15.0 RC (2012-03-25 r58832) ]
>
> Paul
>
>>
>> As you can tell, I'm struggling a bit with interpreting the information
>> from the note. Also, if it were a warning I could set it to stop, and
>> then traceback to what was causing the problem. As it is, it took me a
>> fairly long time just to get the fact that the call to dbGetQuery() was
>> generating the message. And caching the methods may be good for
>> performance, but when things change the second time you call them it
>> sure makes debugging difficult.
>>
>> Best,
>> Paul
>>
>>
>> On 12-03-25 03:24 PM, John Chambers wrote:
>>> On 3/24/12 5:43 PM, Paul Gilbert wrote:
>>>>
>>>>
>>>> On 12-03-24 08:11 PM, John Chambers wrote:
>>>>>
>>>>>
>>>>> On 3/24/12 1:29 PM, Paul Gilbert wrote:
>>>>>> (I think this is being caused by the new methods package in RC.)
>>>>> Possibly, but the methods package isn't particularly "new" in its
>>>>> method
>>>>> selection.
>>>>>
>>>>> We need to see the definition of the class.
>>>>
>>>> Is there a way to know which class it is that we need to see the
>>>> definition for?
>>>
>>> It's in the note: 'target signature "TSMySQLConnection#integer"'. In
>>> functional OOP with multiple dispatch, it's all the classes that matter
>>> in general, but in this and most cases, one class is likely the relevant
>>> one: "TSMySQLConnection". That was why I said what I did before.
>>>
>>> (We could go to a bit more effort and back-translate the dispatch string
>>> "TSMySQLConnection#integer" into the corresponding formal arguments.
>>> Would be more natural with the INSTALL time tool I mentioned before.
>>> That's the real challenge here -- to give information about this to the
>>> package developer, not the poor user.)
>>>
>>> John
>>>
>>>>
>>>> Paul
>>>>
>>>>> The note implies that it
>>>>> inherits from both "MySQLConnection" and "dbObjectId", both of which
>>>>> have methods for coercing to "integer". Hence the ambiguity.
>>>>>>
>>>>>> In the RC (March 24) some of my packages are generating a Note
>>>>>>
>>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>>> function "coerce",
>>>>>> target signature "TSMySQLConnection#integer".
>>>>>> "dbObjectId#integer" would also be valid
>>>>>>
>>>>>> This is coming from a call to dbGetQuery() in package DBI. The method
>>>>>> with the signature "TSMySQLConnection#integer" is generated
>>>>>> automatically because TSMySQLConnection inherits from
>>>>>> MySQLConnection. (More details below.)
>>>>>>
>>>>>> Is there a way to pass this information along to coerce when the
>>>>>> method is generated, or otherwise suppress the Note?
>>>>> No. Methods are inherited according to rules implied by the class
>>>>> inheritance; R doesn't allow you to override the inheritance, other
>>>>> than
>>>>> by being more explicit about the method definition. (It's only a note,
>>>>> and IMO a relevant one. Be glad the language isn't Dylan, which treats
>>>>> similar ambiguities as a programming error. :-))
>>>>>>
>>>>>> BTW,
>>>>>> 1/ It would be nice if the Note mentioned what method is generating
>>>>>> it, in addition to the signature. Debugging for a call several levels
>>>>>> deep in the stack is already hard enough.
>>>>> ?? it does, for coerce() which admittedly you have to know is the
>>>>> method
>>>>> defined for as(thing, "integer") either directly or indirectly. Unless
>>>>> you mean showing you the whole method definition, but that seems not
>>>>> relevant to selection.
>>>>>
>>>>> If you wanted to see the coerce() method, you need to do
>>>>> showMethods("coerce"), but I don't think that's relevant. As
>>>>> mentioned,
>>>>> it's the class hierarchy that matters.
>>>>>>
>>>>>> 2/ The note only seems to get generated on the first call and then
>>>>>> gets suppressed. This will be nice for users, but makes debugging
>>>>>> harder. Is there a way to prevent suppressing the message?
>>>>> No. the note is generated when an inherited method is found. That
>>>>> method
>>>>> is then cached, so the computations required are (fortunately) not
>>>>> repeated.
>>>>>
>>>>> It would be nice to have tools that the package writer could apply to
>>>>> generate all possible inheritance patterns, and flag possible
>>>>> ambiguities at package INSTALL time, as opposed to when the package is
>>>>> used. But it's likely that would generate so many cases unlikely to
>>>>> occur that the package developer would ignore it, even assuming the
>>>>> developer was energetic enough to use the tool in the first place.
>>>>>> o
>>>>>> 3/ It seems strange that getMethod() cannot find the methods even
>>>>>> though showMethods() shows it. (See below.)
>>>>> I think you're confusing getMethod(), which only finds directly
>>>>> defined
>>>>> methods, with selectMethod() which replicates the inheritance
>>>>> computations.
>>>>>
>>>>> In any case the selection of the method has been specified for you
>>>>> already.
>>>>>
>>>>> John
>>>>>>
>>>>>> Paul
>>>>>> ________
>>>>>>
>>>>>> >showMethods("dbGetQuery")
>>>>>> Function: dbGetQuery (package DBI)
>>>>>> conn="MySQLConnection", statement="character"
>>>>>>
>>>>>> > z <- TSget("Series 1", con, TSrepresentation="timeSeries")
>>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>>> function "coerce",
>>>>>> target signature "TSMySQLConnection#integer".
>>>>>> "dbObjectId#integer" would also be valid
>>>>>> Loading required package: zoo
>>>>>>
>>>>>> Attaching package: ‘zoo’
>>>>>>
>>>>>> The following object(s) are masked from ‘package:timeSeries’:
>>>>>>
>>>>>> time<-
>>>>>>
>>>>>> The following object(s) are masked from ‘package:base’:
>>>>>>
>>>>>> as.Date, as.Date.numeric
>>>>>>
>>>>>> > showMethods("dbGetQuery")
>>>>>> Function: dbGetQuery (package DBI)
>>>>>> conn="MySQLConnection", statement="character"
>>>>>> conn="TSMySQLConnection", statement="character"
>>>>>> (inherited from: conn="MySQLConnection", statement="character")
>>>>>>
>>>>>> > getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>>> statement="character"))
>>>>>> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>>> statement = "character")) :
>>>>>> No method found for function "dbGetQuery" and signature
>>>>>> TSMySQLConnection, character
>>>>>> >
>>>>>>
>>>>>> ______________________________________________
>>>>>> [hidden email] mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>
>>>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Paul Gilbert-2]

On 12-03-26 02:47 PM, John Chambers wrote:

> This direction is perhaps adding to the confusion rather than reducing it.
>
> Let's go back to the original note:
>
> Note: Method with signature "MySQLConnection#integer" chosen for
> function "coerce",
> target signature "TSMySQLConnection#integer".
> "dbObjectId#integer" would also be valid
>
> The purpose of the note is just to make you (the programmer) aware that
> in fact two methods are available for coercing from "TSMySQLConnection"
> to "integer". Which do you want, if either?
>
> If it's not the one from "MySQLConnection" then one needs to say
> explicitly what it should be. In any case, being explicit would remove
> the note, if that's what is bothering people.
>
> The "coerce" generic is abnormal, in that its methods are rarely
> specified directly, but via a setAs() call and it's never invoked
> directly, but rather from an as(thing, "integer")--this may in part be
> why the behavior is confusing.
>
> If you have an example that produces the note, the relevant methods can
> be examined by following that example with
> getMethod("coerce", c("MySQLConnection","integer"))
> getMethod("coerce", c("dbObject","integer"))
> You DO have to wait until the note is produced because the as()
> calculations may install methods for coerce() in response to particular
> calls.
>
> Then it's likely you want to insert a
> setAs("TSMySQLConnection", "integer", ....)
> into the package that defines "TSMySQLConnection", with the chosen
> definition.

Ok, if I understand correctly, when my code made the call to
dbExistsTable(), a method for "coerce" with signature
c("MySQLConnection","integer") was automatically generated. I can see
that when I do showMethods("coerce"):

from="MySQLConnection", to="integer"
   (inherited from: from="dbObjectId", to="integer")

and also from looking at the RMySQL package source and seeing that
    setAs("MySQLConnection", "integer", ....)
has not been done.

Then when I execute

   dbGetQuery(con, "show tables")

the note reflects that it has to choose between the automatically
generated one and the one that the automatically generated one was
inherited from, so there is an ambiguity. If I do not do dbExistsTable()
first, then the automatically generated one has not been generated yet,
so there is no ambiguity and I do not get the note.

I can prevent getting the note by using

    setAs("TSMySQLConnection", "integer",
   def=getMethod("coerce", c("dbObjectId","integer")))

in my package. It make sense to specify the original rather than the
automatically generated one, but I am still a bit confused why the note
says it is using the automatically generated one, but if I try to set
that one explicitly I get an error:

 > dbGetQuery(con, "show tables")
Note: Method with signature "MySQLConnection#integer" chosen for
function "coerce",
  target signature "TSMySQLConnection#integer".
  "dbObjectId#integer" would also be valid
    Tables_in_test
1               A
2               B

 > setAs("TSMySQLConnection", "integer",
+   def=getMethod("coerce", c("MySQLConnection","integer")))
Error in getMethod("coerce", c("MySQLConnection", "integer")) :
   No method found for function "coerce" and signature MySQLConnection,
integer
 >
(A this point I think I have a fix, so this is just for my general
understanding.)

> Just to repeat: This is a "Note" and doesn't necessarily indicate a bug.

Even though in my case either would have worked, my feeling is that
there could be cases where it is a problem, so package developers should
be using setAs() explicitly to reduce ambiguities, as you say. And
because of this you should be issuing a warning not just a note. And, if
you do issue a warning, then that makes it a bug in my package, so I
want to fix it.

Thanks again,
Paul

> It's in the nature of functional OOP with multiple dispatch that there
> can be multiple eligible methods. It may or may not matter which is
> chosen, and one can't guarantee that any automatic selection will get
> the "right" one. It's nearly always helpful to be as specific as
> possible where ambiguities do exist.
>
> John
>
> On 3/26/12 6:23 AM, Paul Gilbert wrote:
>>
>>
>> On 12-03-25 05:29 PM, Paul Gilbert wrote:
>>> John
>>>
>>> Here is the definition of the TSMySQLConnection class, and a few other
>>> things. This is a simplified example that produces the message, but
>>> unfortunately will not work unless you have a MySQL database to connect
>>> to. (I do get the same problem with PostgreSQL, and may with SQLLite,
>>> but I have not tested the last yet.)
>>>
>>> require("methods")
>>> require("DBI")
>>> require("RMySQL")
>>>
>>> setClassUnion("OptionalPOSIXct", c("POSIXct", "logical"))
>>> setClass("conType", representation( drv="character"), "VIRTUAL" )
>>>
>>> setClass("TSdb", representation( dbname="character",
>>> hasVintages="logical", hasPanels="logical"), "VIRTUAL" )
>>>
>>>
>>> setClass("TSMySQLConnection", contains=c("MySQLConnection", "conType",
>>> "TSdb"))
>>>
>>>
>>> setGeneric("TSconnect", def= function(drv, dbname, ...)
>>> standardGeneric("TSconnect"))
>>>
>>>
>>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>>> definition=function(drv, dbname, ...) {
>>> con <- dbConnect(drv, dbname=dbname, ...)
>>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>>> hasVintages=dbExistsTable(con, "vintageAlias"),
>>> hasPanels =dbExistsTable(con, "panels"))
>>> })
>>>
>>> con <- TSconnect(dbDriver("MySQL"), "test")
>>>
>>> dbGetQuery(con, "show tables")
>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>> function "coerce",
>>> target signature "TSMySQLConnection#integer".
>>> "dbObjectId#integer" would also be valid
>>> Tables_in_test
>>> 1 A
>>> 2 B
>>> >
>>>
>>> The message also seems to go away, even quitting R and restarting to
>>> clear the cache, if I change the TSconnect method as follow
>>>
>>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>>> definition=function(drv, dbname, ...) {
>>> con <- dbConnect(drv, dbname=dbname, ...)
>>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>>> hasVintages=FALSE,
>>> hasPanels =FALSE)
>>> })
>>>
>>> Why this would happen makes absolutely no sense to me. In the first
>>> version is dbExistsTable(con, "vintageAlias") left unevaluated in the
>>> result from new?
>>
>> This is very strange. With
>>
>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>> definition=function(drv, dbname, ...) {
>> con <- dbConnect(drv, dbname=dbname, ...)
>> hasVintages <- as.logical(dbExistsTable(con, "vintageAlias") )
>> hasPanels <- as.logical(dbExistsTable(con, "panels") )
>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>> hasVintages=FALSE,
>> hasPanels =FALSE)
>> })
>>
>> I get the note, but if I remove the two lines that appear to do nothing:
>>
>> setMethod("TSconnect", signature(drv="MySQLDriver", dbname="character"),
>> definition=function(drv, dbname, ...) {
>> con <- dbConnect(drv, dbname=dbname, ...)
>> new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
>> hasVintages=FALSE,
>> hasPanels =FALSE)
>> })
>>
>> I no longer get the note. I am restarting R each time to be sure nothing
>> is cached.
>>
>> [ R version 2.15.0 RC (2012-03-25 r58832) ]
>>
>> Paul
>>
>>>
>>> As you can tell, I'm struggling a bit with interpreting the information
>>> from the note. Also, if it were a warning I could set it to stop, and
>>> then traceback to what was causing the problem. As it is, it took me a
>>> fairly long time just to get the fact that the call to dbGetQuery() was
>>> generating the message. And caching the methods may be good for
>>> performance, but when things change the second time you call them it
>>> sure makes debugging difficult.
>>>
>>> Best,
>>> Paul
>>>
>>>
>>> On 12-03-25 03:24 PM, John Chambers wrote:
>>>> On 3/24/12 5:43 PM, Paul Gilbert wrote:
>>>>>
>>>>>
>>>>> On 12-03-24 08:11 PM, John Chambers wrote:
>>>>>>
>>>>>>
>>>>>> On 3/24/12 1:29 PM, Paul Gilbert wrote:
>>>>>>> (I think this is being caused by the new methods package in RC.)
>>>>>> Possibly, but the methods package isn't particularly "new" in its
>>>>>> method
>>>>>> selection.
>>>>>>
>>>>>> We need to see the definition of the class.
>>>>>
>>>>> Is there a way to know which class it is that we need to see the
>>>>> definition for?
>>>>
>>>> It's in the note: 'target signature "TSMySQLConnection#integer"'. In
>>>> functional OOP with multiple dispatch, it's all the classes that matter
>>>> in general, but in this and most cases, one class is likely the
>>>> relevant
>>>> one: "TSMySQLConnection". That was why I said what I did before.
>>>>
>>>> (We could go to a bit more effort and back-translate the dispatch
>>>> string
>>>> "TSMySQLConnection#integer" into the corresponding formal arguments.
>>>> Would be more natural with the INSTALL time tool I mentioned before.
>>>> That's the real challenge here -- to give information about this to the
>>>> package developer, not the poor user.)
>>>>
>>>> John
>>>>
>>>>>
>>>>> Paul
>>>>>
>>>>>> The note implies that it
>>>>>> inherits from both "MySQLConnection" and "dbObjectId", both of which
>>>>>> have methods for coercing to "integer". Hence the ambiguity.
>>>>>>>
>>>>>>> In the RC (March 24) some of my packages are generating a Note
>>>>>>>
>>>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>>>> function "coerce",
>>>>>>> target signature "TSMySQLConnection#integer".
>>>>>>> "dbObjectId#integer" would also be valid
>>>>>>>
>>>>>>> This is coming from a call to dbGetQuery() in package DBI. The
>>>>>>> method
>>>>>>> with the signature "TSMySQLConnection#integer" is generated
>>>>>>> automatically because TSMySQLConnection inherits from
>>>>>>> MySQLConnection. (More details below.)
>>>>>>>
>>>>>>> Is there a way to pass this information along to coerce when the
>>>>>>> method is generated, or otherwise suppress the Note?
>>>>>> No. Methods are inherited according to rules implied by the class
>>>>>> inheritance; R doesn't allow you to override the inheritance, other
>>>>>> than
>>>>>> by being more explicit about the method definition. (It's only a
>>>>>> note,
>>>>>> and IMO a relevant one. Be glad the language isn't Dylan, which
>>>>>> treats
>>>>>> similar ambiguities as a programming error. :-))
>>>>>>>
>>>>>>> BTW,
>>>>>>> 1/ It would be nice if the Note mentioned what method is generating
>>>>>>> it, in addition to the signature. Debugging for a call several
>>>>>>> levels
>>>>>>> deep in the stack is already hard enough.
>>>>>> ?? it does, for coerce() which admittedly you have to know is the
>>>>>> method
>>>>>> defined for as(thing, "integer") either directly or indirectly.
>>>>>> Unless
>>>>>> you mean showing you the whole method definition, but that seems not
>>>>>> relevant to selection.
>>>>>>
>>>>>> If you wanted to see the coerce() method, you need to do
>>>>>> showMethods("coerce"), but I don't think that's relevant. As
>>>>>> mentioned,
>>>>>> it's the class hierarchy that matters.
>>>>>>>
>>>>>>> 2/ The note only seems to get generated on the first call and then
>>>>>>> gets suppressed. This will be nice for users, but makes debugging
>>>>>>> harder. Is there a way to prevent suppressing the message?
>>>>>> No. the note is generated when an inherited method is found. That
>>>>>> method
>>>>>> is then cached, so the computations required are (fortunately) not
>>>>>> repeated.
>>>>>>
>>>>>> It would be nice to have tools that the package writer could apply to
>>>>>> generate all possible inheritance patterns, and flag possible
>>>>>> ambiguities at package INSTALL time, as opposed to when the
>>>>>> package is
>>>>>> used. But it's likely that would generate so many cases unlikely to
>>>>>> occur that the package developer would ignore it, even assuming the
>>>>>> developer was energetic enough to use the tool in the first place.
>>>>>>> o
>>>>>>> 3/ It seems strange that getMethod() cannot find the methods even
>>>>>>> though showMethods() shows it. (See below.)
>>>>>> I think you're confusing getMethod(), which only finds directly
>>>>>> defined
>>>>>> methods, with selectMethod() which replicates the inheritance
>>>>>> computations.
>>>>>>
>>>>>> In any case the selection of the method has been specified for you
>>>>>> already.
>>>>>>
>>>>>> John
>>>>>>>
>>>>>>> Paul
>>>>>>> ________
>>>>>>>
>>>>>>> >showMethods("dbGetQuery")
>>>>>>> Function: dbGetQuery (package DBI)
>>>>>>> conn="MySQLConnection", statement="character"
>>>>>>>
>>>>>>> > z <- TSget("Series 1", con, TSrepresentation="timeSeries")
>>>>>>> Note: Method with signature "MySQLConnection#integer" chosen for
>>>>>>> function "coerce",
>>>>>>> target signature "TSMySQLConnection#integer".
>>>>>>> "dbObjectId#integer" would also be valid
>>>>>>> Loading required package: zoo
>>>>>>>
>>>>>>> Attaching package: ‘zoo’
>>>>>>>
>>>>>>> The following object(s) are masked from ‘package:timeSeries’:
>>>>>>>
>>>>>>> time<-
>>>>>>>
>>>>>>> The following object(s) are masked from ‘package:base’:
>>>>>>>
>>>>>>> as.Date, as.Date.numeric
>>>>>>>
>>>>>>> > showMethods("dbGetQuery")
>>>>>>> Function: dbGetQuery (package DBI)
>>>>>>> conn="MySQLConnection", statement="character"
>>>>>>> conn="TSMySQLConnection", statement="character"
>>>>>>> (inherited from: conn="MySQLConnection", statement="character")
>>>>>>>
>>>>>>> > getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>>>> statement="character"))
>>>>>>> Error in getMethod("dbGetQuery", signature = c("TSMySQLConnection",
>>>>>>> statement = "character")) :
>>>>>>> No method found for function "dbGetQuery" and signature
>>>>>>> TSMySQLConnection, character
>>>>>>> >
>>>>>>>
>>>>>>> ______________________________________________
>>>>>>> [hidden email] mailing list
>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>>
>>>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel