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

Paul Gilbert pgilbert902 at gmail.com
Mon Aug 26 21:12:49 CEST 2013



On 13-08-26 12:04 PM, Gavin Simpson wrote:
> 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.

Either I am messing up something again (reasonably likely) or it does 
just work with S4 methods. I can import the namespace that has the 
generic and the methods work, I do not seem to need to export the 
generic.  Is S3 working differently? I do have the documentation problem 
when I try to export other imported functions that I would like 
available to users.

Paul
>
> 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
>
>
>



More information about the R-devel mailing list