> in some sense you'd want it to be local to the package code when the > package is not attached, but that's not supported in R as it is now.
Lexically scoped methods work well (e.g. all methods in the base package) but they are discouraged by a WARNING in R CMD check: ``` Found the following apparent S3 methods exported but not registered: as.character.formula See section ‘Registering S3 methods’ in the ‘Writing R Extensions’ manual. ``` I think that's too bad because they seem like a legitimate way of providing encapsulated dispatch. Lionel > On 1 sept. 2017, at 14:49, Simon Urbanek <simon.urba...@r-project.org> wrote: > > Really, we have three levels of behavior related to dispatch: not loaded, > loaded and attached. The loaded state is the most fragile - it does change > some behavior (like the one below) but not others (when the package defines a > new version of a generic). So it is true that the dispatch is the most > problematic, in some sense you'd want it to be local to the package code when > the package is not attached, but that's not supported in R as it is now. > > Martin, re :: - I strongly disagree, semantically I find :: much cleaner than > imports because you know exactly which function you call at all times and you > don't pollute you package unnecessarily. It is unfortunate that the construct > is inefficient in R, but that's an implementation problem, it shouldn't be > because in fact it's immediately clear which symbol is meant. I believe the > compiler should be able to fix that so in principle it shouldn't make a > difference performance wise. > > Cheers, > Simon > > >> On Sep 1, 2017, at 8:03 AM, Martin Maechler <maech...@stat.math.ethz.ch> >> wrote: >> >>>>>>> Lionel Henry <lio...@rstudio.com> >>>>>>> on Fri, 1 Sep 2017 13:47:07 +0200 writes: >> >>> A package should probably never register a S3 method unless it owns >>> either the generic or the class. >> >> I agree... (and typically it does "own" the class) >> >>> Here `formula.tools` owns neither. >> >> i.e., it neither defines as.character() nor class "formula". >> >>> Instead of registering the method, it should export it like a regular >>> function. This way S3 dispatch is based on lexical scoping rather than >>> session-wide side effect. >> >> I don't the 2nd sentence above is quite correct. S3 method >> registration should be done (in the case it should) and S3 >> dispatch is not just based on lexical scoping but also on S3 >> method registration. >> >>> Lionel >> >> It is still the case that :: silently loads the namespace if >> needed, and that "things may behave differently" after the use '::', because >> loading a namespace does have an effect on the R session ..., >> (and I still think `::` is much "over used") >> >> Martin >> >> >> >>>> On 1 sept. 2017, at 12:57, Simon Barthelmé <simon.barthe...@gipsa-lab.fr> >>>> wrote: >>>> >>>> Dear list >>>> >>>> I'm not sure whether this is a bug or an unavoidable consequence of the >>>> way packages are loaded, but there can be surprising side effects of >>>> calling a function via package::function. Here's an example using the >>>> formula.tools package: >>>> >>>> form <- a ~ b >>>> as.character(form) >>>> formula.tools::lhs(form) >>>> as.character(form) >>>> >>>> The first call to as.character returns: >>>> [1] "~" "a" "b" >>>> The second returns: >>>> [1] "a ~ b" >>>> >>>> The reason being that formula.tools has: >>>> S3method(as.character,formula) >>>> in its namespace, which quietly supersedes the default one. In my case it >>>> led to a bug that was rather hard to track down because it looked like >>>> non-deterministic behaviour. >>>> Shouldn't there at least be a warning about such side effects, the way >>>> library() tells you about masking? >>>> >>>> Best >>>> >>>> Simon Barthelme >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
