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:
> `:::`
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
