Re: [Rd] Questions about name space directives

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Wed, 02 May 2007 08:56:16 +0100 (BST)

On Tue, 1 May 2007, Seth Falcon wrote:

> Hi,
>
> I'm hoping to get some clarification of the intent of some of
> directives used in NAMESPACE files.

For 'intent' you would have to get a response from the authors. Pending that, here are some comments on what they implemented.

> 1. Is import(somePkg) also intended to import all classes and methods
> that are exported via exportClasses and exportMethods in somePkg?
> I think import pulls in classes and methods, but it isn't clear
> from the docs whether this is as intended.

`Import' and `export' are not being used in the everyday sense. export() in a name space is to do with whether objects in the name space are in the package environment (as distinct from the name space environment). import() imports the name space and not the package environment. As the classes, methods and any created generics are in the name space, they are _all_ imported by import(somePkg) (whether exported or not).

However, for methods on generics not in the same package you need to do more than import them: you need to tell the S4 dispatch mechanisms about them. At that point there seem to be some differences between import() and importMethodsFrom() that I do not currently understand, relating to importing methods from more than one namespace and merging the methods tables. (I suspect that the differences, if real, are unintentional.)

Using importMethods() also imports the corresponding generics if they are in the namespace being imported from, but that is best thought of as an implementation detail.

> 2. What is exportMethods intended to do? I'm confused about when/if
> exportMethods deals with a generic function vs method(s) for a
> generic function.
>
> a) In a package that defines a generic function "foo" via
> setGeneric, it seems to be sufficient to use
> exportMethods("foo") to export the generic (and any methods
> defined). Is this as intended or should the author add an
> export("foo") directive to explicitly export the generic
> function?

Naming a generic in exportMethods() will export the generic if it is in the namespace. Conversely, exporting a generic will export its methods (namespace.R:406).

> b) In a package that only sets methods on generic "foo", an
> exportMethods("foo") directive does not re-export the "foo"
> generic. I find it confusing that exportMethods sometimes
> exports the generic and sometimes not. The generic can be
> re-exported using export().

I don't know what you mean by 're-export' here, but I think that relates to using these terms in the everyday sense. I guess you are saying that if you import a generic (which need not have been exported) from another name space, that is not exported by exportMethods. That is correct according to my previous para: that generic was never 'in' the name space but in its enclosing environment. As export() works not just on the name space but also its imports, you can explicitly export a generic you imported. (All you need in order to be able to export an object is for it to be visible from the name space when the latter is loaded.)

I'll look into adding a bit more to `Writing R Extensions', but some of this is implementation detail that we do not necessarily wish to enshrine in the API. (OTOH, changing it is likely to break things nowadays.)

Brian

-- 
Brian D. Ripley,                  ripley_at_stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Wed 02 May 2007 - 08:00:46 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 02 May 2007 - 11:33:33 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.