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" <j...@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 <maech...@stat.math.ethz.ch> wrote:
>> >>>>> John Fox <j...@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@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
