This is a topic ' "apparent S3 methods" note in R CMD check '
from R-package-devel
https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html
which is relevant to here because some of us have been thinking
about extending R because of the issue.
John Fox, maintainer of the 'effects' package has enquired about
the following output from 'R CMD check effects'
>> * checking S3 generic/method consistency ... NOTE
>> Found the following apparent S3 methods exported but not
registered:
>> all.effects
and added
>> 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()?
and I had agreed that this was a "False Positive" in this case.
[.......]
and then
> 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.
and actually I did *not* cross post, but have now moved the
relevant part of the thread to R-devel.
Martin Maechler,
ETH Zurich
And my non-cross-posted cross-posting: "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 10:12:07 +0200 Martin Maechler <maechler at stat.math.ethz.ch> wrote:> This is a topic ' "apparent S3 methods" note in R CMD check ' > from R-package-devel > https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html > > which is relevant to here because some of us have been thinking > about extending R because of the issue. > > John Fox, maintainer of the 'effects' package has enquired about > the following output from 'R CMD check effects' > > >> * checking S3 generic/method consistency ... NOTE > >> Found the following apparent S3 methods exported but not registered: > >> all.effects > > and added > > >> 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()? > > and I had agreed that this was a "False Positive" in this case. > > [.......] > > and then > > > 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. > > and actually I did *not* cross post, but have now moved the > relevant part of the thread to R-devel. > > Martin Maechler, > ETH Zurich > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel------------------------------------------------ John Fox, Professor McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/
On 12/06/2015 4:12 AM, Martin Maechler wrote:> This is a topic ' "apparent S3 methods" note in R CMD check ' > from R-package-devel > https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html > > which is relevant to here because some of us have been thinking > about extending R because of the issue. > > John Fox, maintainer of the 'effects' package has enquired about > the following output from 'R CMD check effects' > > >> * checking S3 generic/method consistency ... NOTE > >> Found the following apparent S3 methods exported but not registered: > >> all.effects > > and added > > >> 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()? > > and I had agreed that this was a "False Positive" in this case. > > [.......] > > and then > > > 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. > > and actually I did *not* cross post, but have now moved the > relevant part of the thread to R-devel. >It sounds like a good idea. It's a nontrivial amount of work, because of the "all the other S3 method code" part. There's the question of functions defined outside of packages: presumably they are still S3 methods, with no way to suppress that. Duncan
On 12/06/2015 6:41 AM, John Fox wrote:> And my non-cross-posted cross-posting: > > "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.I think these are separate questions: all.effects() could be exported or not, and independently could be an S3 method or not. Duncan Murdoch> Best, > John" > > On Fri, 12 Jun 2015 10:12:07 +0200 > Martin Maechler <maechler at stat.math.ethz.ch> wrote: >> This is a topic ' "apparent S3 methods" note in R CMD check ' >> from R-package-devel >> https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html >> >> which is relevant to here because some of us have been thinking >> about extending R because of the issue. >> >> John Fox, maintainer of the 'effects' package has enquired about >> the following output from 'R CMD check effects' >> >> >> * checking S3 generic/method consistency ... NOTE >> >> Found the following apparent S3 methods exported but not registered: >> >> all.effects >> >> and added >> >> >> 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()? >> >> and I had agreed that this was a "False Positive" in this case. >> >> [.......] >> >> and then >> >> > 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. >> >> and actually I did *not* cross post, but have now moved the >> relevant part of the thread to R-devel. >> >> Martin Maechler, >> ETH Zurich >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ------------------------------------------------ > John Fox, Professor > McMaster University > Hamilton, Ontario, Canada > http://socserv.mcmaster.ca/jfox/ > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
>>>>> Duncan Murdoch writes:> On 12/06/2015 4:12 AM, Martin Maechler wrote: >> This is a topic ' "apparent S3 methods" note in R CMD check ' >> from R-package-devel >> https://stat.ethz.ch/pipermail/r-package-devel/2015q2/000126.html >> >> which is relevant to here because some of us have been thinking >> about extending R because of the issue. >> >> John Fox, maintainer of the 'effects' package has enquired about >> the following output from 'R CMD check effects' >> >> >> * checking S3 generic/method consistency ... NOTE >> >> Found the following apparent S3 methods exported but not registered: >> >> all.effects >> >> and added >> >> >> 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()? >> >> and I had agreed that this was a "False Positive" in this case. >> >> [.......] >> >> and then >> >> > 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. >> >> and actually I did *not* cross post, but have now moved the >> relevant part of the thread to R-devel. >>> It sounds like a good idea. It's a nontrivial amount of work, because > of the "all the other S3 method code" part. There's the question of > functions defined outside of packages: presumably they are still S3 > methods, with no way to suppress that.I am not sure this is the right solution: S3 dispatch will still occur because we first look at foo.bar exports and then in the S3 registry, afaicr (the "all the other S3 method code" part). If we could move to only looking at the registry for dispatch, there would be no need to declare situations where we should not dispatch on foo.bar exports. -k