From ucfagls at gmail.com  Mon Aug 26 18:04:44 2013
From: ucfagls at gmail.com (Gavin Simpson)
Date: Mon, 26 Aug 2013 10:04:44 -0600
Subject: [Rd] Correct NAMESPACE approach when writing an S3 method for a
 generic in another package
In-Reply-To: <CAFDcVCS0+qtPH3qBMOgouYhEg0-vzuh7xK7Y11GoMT+_C_1LxA@mail.gmail.com>
References: <CAAHES9yT-YM=huPWJ+Wgv7y8RQV3n=hX8cHOMYXrCLNc7A4e4g@mail.gmail.com>
	<1377505726.5290.20.camel@braque.iarc.fr>
	<CAFDcVCS0+qtPH3qBMOgouYhEg0-vzuh7xK7Y11GoMT+_C_1LxA@mail.gmail.com>
Message-ID: <CAAHES9zPndYwgDuH2bVyFmMmUj2rnfhBYTddRpAoiASRhoUnsw@mail.gmail.com>

Right Henrik, but then you have to document it or R CMD check raises a
Warning, which is less likely to pass muster when submitting to CRAN.
So you document that method on your existing method's Rd page (just
via an \alias{}), which is fine until the user does end up attaching
the original source of the method, and then you get the annoying
warnings about masking and `?plot3d` will bring up a dialogue asking
which version of the help you want to read.

Part of me thinks it would be better if there was a mechanism whereby
a generic will just work if package foo imports that generic and
exports a method for it.

Cheers,

G

On 26 August 2013 09:42, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:
> On Mon, Aug 26, 2013 at 1:28 AM, Martyn Plummer <plummerm at iarc.fr> wrote:
>> I think rgl should be in Depends.  You are providing a method for a
>> generic function from another package. In order to use your method, you
>> want the user to be able to call the generic function without scoping
>> (i.e. without calling rgl::plot3d), so the generic should be on the
>> search path, so the package that provides it should be listed in Depends
>> in the NAMESPACE file.
>
> You can re-export an imported object, but it has to be done via an
> explicit export(), cf. "It is possible to export variables from a
> namespace which it has imported from other namespaces: this has to be
> done explicitly and not via exportPattern" [Writing R Extensions].
>
> /H
>
>>
>> Martyn
>>
>> On Fri, 2013-08-23 at 22:01 -0600, Gavin Simpson wrote:
>>> Dear List,
>>>
>>> In one of my packages I have an S3 method for the plot3d generic
>>> function from package rgl. I am trying to streamline my Depends
>>> entries but don't know how to have
>>>
>>> plot3d(foo)
>>>
>>> in the examples section for the plot3d method in my package, without
>>> rgl being in Depends.
>>>
>>> Note that I importFrom(rgl, plotd3d) and register my S3 method via
>>> S3Method() in the NAMESPACE.
>>>
>>> If rgl is not in Depends but in Imports, I see this when checking the package
>>>
>>> > ## 3D plot of data with curve superimposed
>>> > plot3d(aber.pc, abernethy2)
>>> Error: could not find function "plot3d"
>>>
>>> I presume this is because rgl's namespace is only loaded but the
>>> package is not attached to the search path.
>>>
>>> Writing R extensions indicates that one can export from a namespace
>>> something that was imported from another package namespace. I thought
>>> that might help the situation, and now the code doesn't raise an
>>> error, I get
>>>
>>> * checking for missing documentation entries ... WARNING
>>> Undocumented code objects:
>>>   ?plot3d?
>>> All user-level objects in a package should have documentation entries.
>>> See the chapter ?Writing R documentation files? in the ?Writing R
>>> Extensions? manual.
>>>
>>> as I don't document plot3d() itself.
>>>
>>> What is the recommended combination of Depends and Imports plus
>>> NAMESPACE directives etc that one should use in this situation? Or am
>>> I missing something else?
>>>
>>> I have a similar issue with my package including an S3 method for a
>>> generic in the lattice package, so if possible I could get rid of both
>>> of these from Depends if I can solve the above issue.
>>>
>>> Thanks in advance.
>>>
>>> Gavin
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Gavin Simpson, PhD



[Rd] Correct NAMESPACE approach when writing an S3 method for a generic in another package
Gavin Simpson