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

[Martin Maechler]

>>>>> Uwe Ligges <ligges at statistik.tu-dortmund.de>
>>>>>     on Fri, 12 Jun 2015 22:58:17 +0200 writes:

    > 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

> 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:
>
>> 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:
>>>>>>>> John Fox <jfox at mcmaster.ca>
>>>>>>>>      on Wed, 10 Jun 2015 10:12:46 -0400 writes:
>>>
>>>      > 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