[Rd] RFC: Declaring "foo.bar" as nonS3method() ?!

[Duncan Murdoch]

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