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-methodall,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