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

[Kurt Hornik]

>>>>> Duncan Murdoch writes:

> 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.

Yep---that's what I meant.  I forgot to write the "if namespace
semantics applies" part :-)

Best
-k

> 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