From murdoch.duncan at gmail.com  Thu Aug 29 13:19:42 2013
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 29 Aug 2013 07:19:42 -0400
Subject: [Rd] =?windows-1252?q?=91=3A=3A=3A=92_call?=
In-Reply-To: <CAC2h7uuau6A7YQ=GaghBACqjRdv_Mh3WgOC-=6az9avLxkUExA@mail.gmail.com>
References: <521E221E.3020107@gmail.com>
	<E340A230-94C4-4ED3-BD42-0C72F8CAC340@me.com>
	<521E4666.8080603@gmail.com>
	<CAC2h7utx9=Guxidk3Bt1f42=yobbqRSk3ZE0eRC89np+r1JUrA@mail.gmail.com>
	<521E4DDE.8010404@gmail.com>
	<CAC2h7uuau6A7YQ=GaghBACqjRdv_Mh3WgOC-=6az9avLxkUExA@mail.gmail.com>
Message-ID: <521F2E4E.7080909@gmail.com>

On 13-08-28 9:00 PM, Kasper Daniel Hansen wrote:
>
>
>
> On Wed, Aug 28, 2013 at 3:22 PM, Duncan Murdoch
> <murdoch.duncan at gmail.com <mailto:murdoch.duncan at 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
>         <pgilbert902 at gmail.com <mailto:pgilbert902 at gmail.com>> wrote:
>
>          > On 13-08-28 12:29 PM, Marc Schwartz wrote:
>          >
>          >>
>          >> On Aug 28, 2013, at 11:15 AM, Paul Gilbert
>         <pgilbert902 at gmail.com <mailto:pgilbert902 at 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 at r-project.org <mailto:R-devel at 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 at r-project.org <mailto:R-devel at r-project.org> mailing list
>         https://stat.ethz.ch/mailman/__listinfo/r-devel
>         <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
>
>



[Rd] =?windows-1252?q?=91=3A=3A=3A=92_call?=
Duncan Murdoch