>>>>> Hadley Wickham <h.wick...@gmail.com> >>>>> on Fri, 12 Jun 2015 09:53:20 -0500 writes:
> To me, it seems like there's actually two problems here: > 1) Preventing all() from dispatching to all.effects() for objects of > class effects > 2) Eliminating the NOTE in R CMD check Sure. ... and that what I said in my OP > My impression is that 1) actually causes few problems, particularly > since people are mostly now aware of the problem and avoid using `.` > in function names unless they're S3 methods. Fixing this issue seems > like it would be a lot of work for relatively little gain. Well, we may disagree here. I did mean to improve the system "deep down", and Kurt and Duncan where basically also blowing the same trumpet. We are not re-inventing all the wheels on all the cars that have been racing around - sometimes for decennia... and so some names have been there for a long time and will remain. > However, I think we want to prevent people from writing new functions > with this confusing naming scheme, but equally we want to grandfather > in existing functions, because renaming them all would be a lot of > work (I'm looking at you t.test()!). exactly. > Could we have a system similar to globalVariables() where you could > flag a function as definitely not being an S3 method? did you read what I wrote originally? Exactly that - with a working-proposition nonS3method("<name>") And BTW ---- I'm diverting and I seem to "preach" in vain here, but in my view globalVariables("xy") is really a very very poor "solution" and far from what one would desire: If you use it in your package, say because one function uses non-standard evaluation and hence 'xy', *all* erronous global uses of 'xy in all other functions in your package will *not* be flagged by the nice codetools package functionality which is behind that part of R CMD check. Martin > I'm not sure what R CMD check should do - ideally you > wouldn't be allow to use method.class for new functions, > but still be able suppress the note for old functions that > can't easily be changed. > Hadley > On Fri, Jun 12, 2015 at 6:52 AM, Kurt Hornik <kurt.hor...@wu.ac.at> wrote: >>>>>>> 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 >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > -- > http://had.co.nz/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel