On 12/06/2015 7:16 AM, Kurt Hornik wrote: >>>>>> 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. >
I think that would break a lot of existing scripts. I think the logic should be something like this. For each class in the class list: Search backwards through the environment chain. If the current location is a package environment or namespace, look only in the registry. If not, look at all functions. If that search failed, try the next class. A variation on the test is: If there's a registry in the current location, look there. But I think the registry is not on the search list, so I'm not sure that would work. This assumes that we keep separate registries in each package; if we merge them into one big registry, it gets harder. I'm not familiar enough with the code to know which way we do it. Duncan Murdoch ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
