Yihui, On Sun, Aug 25, 2013 at 7:53 PM, Yihui Xie <x...@yihui.name> wrote:
> I know it is really bad, but the so-called good approach can be more > expensive than that <snip> > It is more expensive for you, yes. On the other hand, I'm pretty sure if everyone were running around circumventing whatever CRAN tests they were annoyed with at the time that situation would be enormously more expensive for the R community as a whole. > > For this particular case, I can imagine at least one case which can be > endless trouble to CRAN: if the package author A has talked to B to > use a hidden function in B's package, and B thinks that function is > relatively stable but does not want to export it; A may go ahead and > use it via :::. Both A and B understand that unexported function well, > then what should A do when submitting the package to CRAN? Should CRAN > continue adding rules for such exceptions? > > IMO, what you are describing is a straightforward situation in which the function should be exported. If a function is stable, the author is willing to have other people depend on it, and other people want to use it and would find it useful exporting it is the Right Way (tm) of doing that. What is your argument that it should not be exported in this case? To be clear I'm not arguing for outlawing :::, I DO think there are times when it is better than the available alternatives, but I think the type of selective exporting of functions just to the authors close friends that you are describing is toxic to the ecosystem of R packages as a whole. > In other words, "bad" practices almost always have exceptions and edge > cases. Of course, the decision is always in CRAN's hands, and I will > try to respect and follow it as a package author. > The thing about bad practices is that yes, they have exceptions and edge cases, but if the practice really is bad, most of the time someone thinks they are in such an exception/edge case situation, they aren't. This is not an attack on you or any individual person exhibiting "bad practices", but rather a descriptive statement about such things in general. Btw, this applies well beyond coding. Go read James Joyce and then ask an english professor if it's a good idea to write without any punctuation. They will say no, and that any student who did so in their class will be heavily penalized for it. And is that reasonable of them, even though things written without punctuation can be hugely influential high art? I would argue that it is. My opinion on the matter is that the rules are important to follow, even if they aren't quite optimal for any given situation. They aren't designed for any specific situation, to do a pretty good job in the vast majority of situations (and they are completely automated). To be honest I think there is a good case for willfull circumvention of the checks such as you describe being grounds for the package being ejected from CRAN, but its easy for me to say that since I don't have any power. Regardless of the reaction when it is detected (if ever, not sure how it ever would be, I'm sure CRAN is entirely uninterested in an arms race), that type of thing is bad behavior that is orders of magnitude worse than whatever the check was put in place to prevent. If a particular case really is an actual exception, I'm not convinced that having to actually talk to a CRAN person and justify the NOTE is an unreasonable price to be expected to pay. Again, I'm not arguing for the outlawing of :::, in fact I have a patch to R that implements the concept via NAMESPACE mechanics so you could have the package in imports instead of depends and prevent cluttering the search path when this is done. I don't think the situation your describing is a great case for the use of ::: though, and certainly not one that is a good case for CRAN allowing it, as I would imagine (without having any right to speak for them) that CRAN's position is that all packages and authors should be equal in terms of who gets to use what from whom. It is certainly my position on the matter (not that many people care about such things :P) ~G > Regards, > Yihui > -- > Yihui Xie <xieyi...@gmail.com> > Web: http://yihui.name > Department of Statistics, Iowa State University > 102 Snedecor Hall, Ames, IA > > > On Fri, Aug 23, 2013 at 11:05 AM, Duncan Murdoch > <murdoch.dun...@gmail.com> wrote: > > On 13-08-22 11:54 PM, Yihui Xie wrote: > >> > >> Maybe it is not a good idea for R CMD check to check ::: at all, and a > >> warning in R-exts and ?':::' may well be enough. On the other hand, it > >> is just so easy to get around :::, because everybody can see its > >> source code: > > > > > > It's a really bad idea to write tricky code to subvert the tests. If the > > tests are wrong, you can argue for changes (and in this case you did, and > > changes were made), but if you can't give a convincing argument, you > should > > follow the good practices that the repository policies enforce. > > > > Duncan Murdoch > > > >> > >>> `:::` > >> > >> function (pkg, name) > >> { > >> pkg <- as.character(substitute(pkg)) > >> name <- as.character(substitute(name)) > >> get(name, envir = asNamespace(pkg), inherits = FALSE) > >> } > >> > >> Then the package authors who really want to take the risk may start > >> another "hide and seek" game, e.g. > >> > >> `%:::%` = function(pkg, fun) get(fun, envir = asNamespace(pkg), > >> inherits = FALSE) > >> 'stats' %:::% 'Pillai' > -- Gabriel Becker Graduate Student Statistics Department University of California, Davi [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
