Re: [R-pkg-devel] Any new developments on "apparent S3 method" issue?

2017-05-04 Thread Uwe Ligges



On 03.05.2017 18:39, Lenth, Russell V wrote:

Package developers list:

I recently added an 'as.mcmc.list' method for objects in one of my packages. 
Now, in doing an --as-cran check, I get this message:

* checking S3 generic/method consistency ... NOTE
Found the following apparent S3 methods exported but not registered:
  as.mcmc.list
See section 'Registering S3 methods' in the 'Writing R Extensions' manual.

Apparently, the checking routines conclude that I should register an 'as.mcmc' method for class 
"list" -- something that does not exist and is not needed. I did some searching, and 
found an exchange on this issue from January 2015, in which a "nonS3Method()" construct 
was proposed. That sure looks like what is needed, but it still doesn't exist. Is there a different 
way to handle this that has been developed?

Further information -- this is related to the *coda* package, and my NAMESPACE 
file contains this code:

if (requireNamespace("coda", quietly = TRUE)) {
importFrom(coda, as.mcmc, as.mcmc.list)
export(as.mcmc, as.mcmc.list)
S3method(as.mcmc, ref.grid)
S3method(as.mcmc.list, ref.grid)
}

This seems clear enough; and what's mysterious is that *coda* passes the CRAN 
checks without this same NOTE.


Yes. coda had the name for a very long time and it was not reasonable to 
fix this naming in felicity later on, hence there is a check exclusion 
in R-devel/src/library/tools/R/utils.R for as.mcmc.list in package coda.


Best,
Uwe Ligges






As a possible workaround, I am considering:
   -- providing and registering my own S3 method 'as.mcmc' for class "list" --- 
in spite of my disinterest in providing this
  -- not importing coda::as.mcmc.list and instead exporting my own generic that handles 
objects of class "list" separately

Any suggestions?

Russ

Russell V. Lenth  -  Professor Emeritus
Department of Statistics and Actuarial Science
The University of Iowa  -  Iowa City, IA 52242  USA
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Any new developments on "apparent S3 method" issue?

2017-05-04 Thread Lenth, Russell V
OK thanks -- this gives me a new perspective. I see this result:

> tools::nonS3methods("coda")
[1] "as.mcmc.list"

which indicates more about the mechanisms in place for this kind of situation. 
So now it seems that if package 'pkg_B' simply imports and exports a function 
'looks.like.S3.method'  from package 'pkg_A', and 'looks.like.S3.method' is 
already known via tools::nonS3methods("pkg_A") and thus has a check exclusion, 
then 'pkg_B' should have the same check exclusion. I recognize that such a 
check-exclusion-inheritance provision may not be very straightforward to 
implement.

Russ

-Original Message-
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de] 
Sent: Thursday, May 4, 2017 3:06 AM
To: Lenth, Russell V ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Any new developments on "apparent S3 method" issue?



On 03.05.2017 18:39, Lenth, Russell V wrote:
> Package developers list:
>
> I recently added an 'as.mcmc.list' method for objects in one of my packages. 
> Now, in doing an --as-cran check, I get this message:
>
> * checking S3 generic/method consistency ... NOTE Found the following 
> apparent S3 methods exported but not registered:
>   as.mcmc.list
> See section 'Registering S3 methods' in the 'Writing R Extensions' manual.
>
> Apparently, the checking routines conclude that I should register an 
> 'as.mcmc' method for class "list" -- something that does not exist and is not 
> needed. I did some searching, and found an exchange on this issue from 
> January 2015, in which a "nonS3Method()" construct was proposed. That sure 
> looks like what is needed, but it still doesn't exist. Is there a different 
> way to handle this that has been developed?
>
> Further information -- this is related to the *coda* package, and my 
> NAMESPACE file contains this code:
>
> if (requireNamespace("coda", quietly = TRUE)) {
> importFrom(coda, as.mcmc, as.mcmc.list)
> export(as.mcmc, as.mcmc.list)
> S3method(as.mcmc, ref.grid)
> S3method(as.mcmc.list, ref.grid)
> }
>
> This seems clear enough; and what's mysterious is that *coda* passes the CRAN 
> checks without this same NOTE.

Yes. coda had the name for a very long time and it was not reasonable to fix 
this naming in felicity later on, hence there is a check exclusion in 
R-devel/src/library/tools/R/utils.R for as.mcmc.list in package coda.

Best,
Uwe Ligges




>
> As a possible workaround, I am considering:
>-- providing and registering my own S3 method 'as.mcmc' for class "list" 
> --- in spite of my disinterest in providing this
>   -- not importing coda::as.mcmc.list and instead exporting my own 
> generic that handles objects of class "list" separately
>
> Any suggestions?
>
> Russ
>
> Russell V. Lenth  -  Professor Emeritus Department of Statistics and 
> Actuarial Science The University of Iowa  -  Iowa City, IA 52242  USA 
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
>
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


Re: [R-pkg-devel] Any new developments on "apparent S3 method" issue?

2017-05-07 Thread Uwe Ligges



On 04.05.2017 16:23, Lenth, Russell V wrote:

OK thanks -- this gives me a new perspective. I see this result:

> tools::nonS3methods("coda")
[1] "as.mcmc.list"

which indicates more about the mechanisms in place for this kind of situation. So now it 
seems that if package 'pkg_B' simply imports and exports a function 
'looks.like.S3.method'  from package 'pkg_A', and 'looks.like.S3.method' is already known 
via tools::nonS3methods("pkg_A") and thus has a check exclusion, then 'pkg_B' 
should have the same check exclusion. I recognize that such a check-exclusion-inheritance 
provision may not be very straightforward to implement.


Ideally, pkg_B avoids the infelicities that had been established with pkg A.

Best,
Uwe Ligges





Russ

-Original Message-
From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de]
Sent: Thursday, May 4, 2017 3:06 AM
To: Lenth, Russell V ; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Any new developments on "apparent S3 method" issue?



On 03.05.2017 18:39, Lenth, Russell V wrote:

Package developers list:

I recently added an 'as.mcmc.list' method for objects in one of my packages. 
Now, in doing an --as-cran check, I get this message:

* checking S3 generic/method consistency ... NOTE Found the following
apparent S3 methods exported but not registered:
  as.mcmc.list
See section 'Registering S3 methods' in the 'Writing R Extensions' manual.

Apparently, the checking routines conclude that I should register an 'as.mcmc' method for class 
"list" -- something that does not exist and is not needed. I did some searching, and 
found an exchange on this issue from January 2015, in which a "nonS3Method()" construct 
was proposed. That sure looks like what is needed, but it still doesn't exist. Is there a different 
way to handle this that has been developed?

Further information -- this is related to the *coda* package, and my NAMESPACE 
file contains this code:

if (requireNamespace("coda", quietly = TRUE)) {
importFrom(coda, as.mcmc, as.mcmc.list)
export(as.mcmc, as.mcmc.list)
S3method(as.mcmc, ref.grid)
S3method(as.mcmc.list, ref.grid)
}

This seems clear enough; and what's mysterious is that *coda* passes the CRAN 
checks without this same NOTE.


Yes. coda had the name for a very long time and it was not reasonable to fix 
this naming in felicity later on, hence there is a check exclusion in 
R-devel/src/library/tools/R/utils.R for as.mcmc.list in package coda.

Best,
Uwe Ligges






As a possible workaround, I am considering:
   -- providing and registering my own S3 method 'as.mcmc' for class "list" --- 
in spite of my disinterest in providing this
  -- not importing coda::as.mcmc.list and instead exporting my own
generic that handles objects of class "list" separately

Any suggestions?

Russ

Russell V. Lenth  -  Professor Emeritus Department of Statistics and
Actuarial Science The University of Iowa  -  Iowa City, IA 52242  USA
Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel