On 13-08-28 9:00 PM, Kasper Daniel Hansen wrote:



On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch
<murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>> wrote:

    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.


Perhaps you have heard of the concept of "testing".  R actually has good
testing facilities (if you include add-on packages) and these facilities
are very helpful in checking whether the answers provided by a package
are correct. /sarcasm off

How does this argument not apply to *all* tests done by CRAN? Should it stop doing any tests at all, because users can do them if they care?

Duncan Murdoch


And btw. nothing guarantees that the output of an exported function does
not change when the package version change.  Only testing can help you here.

I don't know if CRAN re-checks a package if dependencies change, but
obviously it ought to, from a software validity point of view.

Best,
Kasper

    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 <mailto: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 <mailto: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><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 <mailto:R-devel@r-project.org> mailing list
         > https://stat.ethz.ch/mailman/*__*listinfo/r-devel
        
<https://stat.ethz.ch/mailman/**listinfo/r-devel><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 <mailto:R-devel@r-project.org> mailing list
        https://stat.ethz.ch/mailman/__listinfo/r-devel
        <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