[Rd] legitimate use of :::

[Duncan Murdoch]

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 <xieyihui at 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 <gmbecker at 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 <gray at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>