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