On 28/08/2013 3:06 PM, Kasper Daniel Hansen wrote:
My point of view is that if you have a core package where you need access
to "hidden" functions for making a plugin, you should probably export these
hidden functions in the first place. Chances are that if you need access
to these hidden functions (for expert use), other (expert) users might want
access as well, so take the time to export and document it.
I want to use ::: specifically for the case where I have no control over
the other package.
And as a potential user of your package, I don't want you to use ::: if
you don't have control over the other package, because its author might
unwittingly change it in a way that causes me to get incorrect results.
If you want to use :::, go ahead, just don't put your package on CRAN,
where I get most of my packages. Then we'll both be happy.
Duncan Murdoch
Best,
Kasper
On Wed, Aug 28, 2013 at 2:50 PM, Paul Gilbert <pgilbert...@gmail.com> wrote:
> On 13-08-28 12:29 PM, Marc Schwartz wrote:
>
>>
>> On Aug 28, 2013, at 11:15 AM, Paul Gilbert <pgilbert...@gmail.com> wrote:
>>
>> I have a package (TSdbi) which provides end user functions that I
>>> export, and several utilities for plugin packages (e.g. TSMySQL) that I do
>>> not export because I do not intend them to be exposed to end users. I call
>>> these from the plugin packages using TSdbi::: but that now produces a note
>>> in the checks:
>>>
>>> * checking dependencies in R code ... NOTE
>>> Namespace imported from by a ‘:::’ call: ‘TSdbi’
>>> See the note in ?`:::` about the use of this operator. :: should be
>>> used rather than ::: if the function is exported, and a package
>>> almost never needs to use ::: for its own functions.
>>>
>>> Is there a preferred method to accomplish this in a way that does not
>>> produce a note?
>>>
>>> Thanks,
>>> Paul
>>>
>>
>>
>>
>> Paul,
>>
>> See this rather lengthy discussion that occurred within the past week:
>>
>>
https://stat.ethz.ch/**pipermail/r-devel/2013-August/**067180.html<https://stat.ethz.ch/pipermail/r-devel/2013-August/067180.html>
>>
>> Regards,
>>
>> Marc Schwartz
>>
>
> I did follow the recent discussion, but no one answered the question "Is
> there a preferred method to accomplish this?" (I suppose the answer is that
> there is no other way, given that no one actually suggested anything else.)
> Most of the on topic discussion in that thread was about how to subvert the
> CRAN checks, which is not what I am trying to do and was also pointed out
> as a bad idea by Duncan. The substantive response was
>
> >r63654 has fixed this particular issue, and R-devel will no longer
> >warn against the use of ::: on packages of the same maintainer.
> >
> >Regards,
> >Yihui
>
> but that strikes me as a temporary work around rather than a real
> solution: suppose plugins are provided by a package from another maintainer.
>
> Since CRAN notes have a habit of becoming warnings and then errors, it
> seems useful to identify the preferred legitimate approach while this is
> still a note. That would save work for both package developers and CRAN
> maintainers.
>
> My thinking is that there is a need for a NAMESPACE directive something
> like limitedExport() that allows ::: for identified functions without
> provoking a CRAN complaint when packages use those functions. But there may
> already be a better way I don't know about. Or perhaps the solution is to
> split the end user functions and the utilities for plugin packages into two
> separate packages?
>
> Paul
>
>
> ______________________________**________________
> R-devel@r-project.org mailing list
>
https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>
[[alternative HTML version deleted]]
______________________________________________
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
