Skip to content

[R-pkg-devel] "apparent S3 methods" note in R CMD check

9 messages · Thomas Petzoldt, Xavier Robin, John Fox +3 more

Original
John Fox
# 
Dear list members,

One of the packages I maintain, effects, generates the following note in R
CMD check:

	* checking S3 generic/method consistency ... NOTE
	Found the following apparent S3 methods exported but not registered:
	  all.effects

The offending function, all.effects(), is deprecated in favour of
allEffects(), but I'd rather not get rid of it for backwards compatibility.
Is there any way to suppress the note without removing all.effects()? 

To be clear, all.effects() is *not* a method of all(), and is defined as
function (...) 
{
    .Deprecated("allEffects")
    allEffects(...)
}
<environment: namespace:effects>

Thanks,
 John

-----------------------------------------------
John Fox, Professor
McMaster University
Hamilton, Ontario, Canada
http://socserv.socsci.mcmaster.ca/jfox/




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
1 day later
Martin Maechler
# 
> Dear list members,
    > One of the packages I maintain, effects, generates the following note in R
    > CMD check:

    > * checking S3 generic/method consistency ... NOTE
    > Found the following apparent S3 methods exported but not registered:
    > all.effects

    > The offending function, all.effects(), is deprecated in favour of
    > allEffects(), but I'd rather not get rid of it for backwards compatibility.
    > Is there any way to suppress the note without removing all.effects()? 

    > To be clear, all.effects() is *not* a method of all(), and is defined as

    >> effects::all.effects
    > function (...) 
    > {
    > .Deprecated("allEffects")
    > allEffects(...)
    > }
    > <environment: namespace:effects>

    > Thanks,
    > John

    > -----------------------------------------------
    > John Fox, Professor
    > McMaster University
    > Hamilton, Ontario, Canada
    > http://socserv.socsci.mcmaster.ca/jfox/




    > ---
    > This email has been checked for viruses by Avast antivirus software.
    > https://www.avast.com/antivirus

    > ______________________________________________
    > R-package-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-package-devel
Martin Maechler
# 
> Dear list members,
    > One of the packages I maintain, effects, generates the following note in R
    > CMD check:

    > * checking S3 generic/method consistency ... NOTE
    > Found the following apparent S3 methods exported but not registered:
    > all.effects

    > The offending function, all.effects(), is deprecated in favour of
    > allEffects(), but I'd rather not get rid of it for backwards compatibility.
    > Is there any way to suppress the note without removing all.effects()? 

    > To be clear, all.effects() is *not* a method of all(), and is defined as

    >> effects::all.effects
    > function (...) 
    > {
    >  .Deprecated("allEffects")
    >  allEffects(...)
    > }

Dear John,
this is a good question without an obvious answer for the
moment.

The check producing it is relatively new *and* has helped to
detect problems in many packages and places,  but I would agree
is a "False Positive" in this case.

One reason for such a check is the following output {in R >= 3.2.0},

 > require("effects")
 Loading required package: effects
 > methods(all)
 [1] all,ddiMatrix-method     all,ldiMatrix-method     all,lsparseMatrix-method
 [4] all,Matrix-method        all,nsparseMatrix-method all.effects             
 see '?methods' for accessing help and source code
 >

which wrongly does list your all.effects() among the all
methods.... and indeed (even worse), it *is* taken as S3 method
for all():
 
 > ex <- structure(FALSE, class="effects")
 > all(ex)
 Error: $ operator is invalid for atomic vectors
 In addition: Warning message:
 'all.effects' is deprecated.
 Use 'allEffects' instead.
 See help("Deprecated") 
 > 

---

Now I agree .. and have e-talked about this with another R core
member .. that it would be desirable for the package author to
effectively declare the fact that such a function is not an S3
method even though it "looks like it" at least if looked from far.

So, ideally, you could have something like

 nonS3method("all.effects")

somewhere in your package source ( in NAMESPACE or R/*.R )
which would tell the package-checking code -- but *ALSO* all the other S3
method code that  all.effects should be treated as a regular R
function.

I would very much like such a feature in R, and for that reason,
I'm cross posting this (as one of the famous exceptions that
accompany real-life rules!!) to R-devel.

There is one current work-around -- some would say "hack" -- in the R sources
for exceptions on a per package basis, and I will now activate
that workaround for you.

Martin
Thomas Petzoldt
# 
Dear Martin, dear package developers,

I had a very similar case three days ago in one of our packages. Our aim
was to provide an S3 method matplot.deSolve and an alternative and more
specific non-S3 function matplot.1D because the .1D follows the naming
scheme of other related functions.

The note of R 3.2.0 could be suppressed by (wrongly) declaring the
non-S3 variant as S3method, but finally I decided to use an
S4-compatibility approach instead:


setGeneric("matplot", function(x, ...) graphics::matplot(x, ...))
setOldClass("deSolve")

setMethod("matplot", list(x = "deSolve"), matplot.deSolve)


... with the downside that deSolve::matplot now masks graphics::matplot


So I would appreciate if matplot could be made a generic. Or is there
another way round?

Thomas
Xavier Robin
#
On 10/06/15 16:12, John Fox wrote:
Dear John,

I raised this question on the Rd list a couple of months ago and didn't
get an answer (when asking the CRAN maintainers directly they suggested
to rename the functions).
https://stat.ethz.ch/pipermail/r-devel/2015-February/070630.html

However I recently realized that the tools:::.make_S3_methods_stop_list
function seems to contain a list of non methods. A quick try seems to
indicate that adding my methods there suppressed the note.
I am not sure how to get a function included in the list or if there is
any policy. I am planning to report a bug on Bugzilla and see what happens.

Best wishes,
Xavier
John Fox
# 
Dear Martin,

Thank you for addressing this issue. Introducing a nonS3method() directive in NAMESPACE seems a reasonable solution. It could replace export() for functions with "."s in their names.

Best,
 John

On Fri, 12 Jun 2015 09:55:18 +0200
Martin Maechler <maechler at stat.math.ethz.ch> wrote:
Roebuck,Paul L
# 
Actually, between this and other things coming from 'R CMD check' these
days,
I disagree that this is reasonable at all - it's a hack at best that only
fixes
this particular issue. Better would be to introduce lint-like directives
that
turn off certain R CMD check notes/warnings at different scopes
(e.g., #pylint: disable=some-message,another-one) rather than introduce
individual workarounds. Would give us an extensible version of the
"--no-nanny"
option Kevin wants.
On 6/12/15 5:38 AM, "John Fox" <jfox at mcmaster.ca> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 12.06.2015 18:22, Roebuck,Paul L wrote:

            

      
      
      
    

        
Why a hack? I am not sure what the right mechanism is, but here the 
check is not the problem but it uncovers the problem that the function 
is actually used as an S3 ethod although it is not.

Best,
Uwe Ligges

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        

        
> On 12.06.2015 18:22, Roebuck,Paul L wrote:

        
>> Actually, between this and other things coming from 'R
    >> CMD check' these days, I disagree that this is reasonable
    >> at all - it's a hack

    > Why a hack? I am not sure what the right mechanism is, but
    > here the check is not the problem but it uncovers the
    > problem that the function is actually used as an S3 ethod
    > although it is not.

Indeed. It's really the contrary of hack, namely trying to solve
the underlying problem:
This has been a proposition that is much more than just a way to turn
off some warnings or notes.  It's about a possible improvement in
R in how functions are made into S3 methods, namely allowing at least
for R code in package namespaces (but maybe even outside) to say
that a given  <fn>.<class>  function should *not* be seen as an
S3 method of function <fn> for class <class> .

But please follow up on R-devel -- there's a full thread there.
This list is about helping programmeRs develop their packages ..

Martin