Yihui,

On Sun, Aug 25, 2013 at 7:53 PM, Yihui Xie <xie@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 <xieyihui@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.duncan@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]]

