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'

Non-exported functions do not necessarily imply instability. Maybe it
is just because the author is too lazy to document them, or he/she did
not realize these functions happen to be useful for another author.

Although R-devel does not warn against ::: on the packages of the same
maintainer now, these maintainers may change in the future, or one
maintainer can be an author but not maintainer of another package,
from which he/she imports an unexported function, or package authors
have coordinated well with each other about the unexported functions.
I believe there are other legitimate reasons for :::, which might make
it difficult for R to cover all these cases, and also bring additional
communications between package authors and CRAN.

In conclusion, R CMD check cannot really stop :::, and ::: can be
there for good reasons, so how about just let it go?

Regards,
Yihui
--
Yihui Xie <xieyi...@gmail.com>
Web: http://yihui.name
Department of Statistics, Iowa State University
102 Snedecor Hall, Ames, IA


On Thu, Aug 22, 2013 at 9:02 PM, Gabriel Becker <gmbec...@ucdavis.edu> wrote:
Hey guys,

Because I was curious and had nothing else that I should have been doing
(that second part is a lie), I looked into the namespace code.

I have a working patch that implements importHiddenFrom. It doesn't
currently check whether you then export that symbol (which should not be
allowed) but that would be easy to implement.

Is there any desire from R-core to have add the importHiddenFrom
functionality? If so I can add the export check and submit the patch either
here or on bugzilla. I figure its a long shot but hey, at least I now know
how the namespace stuff works.

I do agree with Peter Meilstrup that poking around at the internals of
someone else's code is often not a good idea, but as others have pointed
out it is done in practice in some fairly high-profile packages, and if its
going to happen it seems like it would be nice to indicate as much in the
NAMESPACE file.

~G


On Thu, Aug 22, 2013 at 5:41 PM, Gray <g...@clhn.co> wrote:

Peter Meilstrup: (05:01PM on Thu, Aug 22)

  One most often encounters namespace conflicts at the user level, when
loading two packages that have no logical connection other than both
bearing on your problem of the moment.


Unless I'm mistaken, you can reassign the hidden functions, ie

fna <- joespackage:::usefulfunction

fnb <- janespackage:::usefulfunction

which is a little bit of a pain, but makes the user's code
unambiguous.  This also works with two colons for explicitly exported
functions.

--
Gray Calhoun, Assistant Professor of Economics at Iowa State
http://gray.clhn.co (web)

______________________________________________
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

Reply via email to