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

[Uwe Ligges]

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.

Best,
Uwe Ligges

> 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
>>>
>>
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>