>>>>> Uwe Ligges <lig...@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" <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