[Rd] S4 Generics and NAMESPACE : justified warning ?

Yohan Chalabi chalabi at phys.ethz.ch
Fri Aug 28 16:24:29 CEST 2009


>>>> "MM" == Martin Morgan <mtmorgan at fhcrc.org>
>>>> on Tue, 18 Aug 2009 06:15:50 -0700

Hi Martin,

Thanks for your response.

   MM> Commenting as a user, there's no guarantee that the 'plot'
   MM> generic
   MM> defined in pkgA is derived from graphics::plot via setGeneric;
   MM> pkgA
   MM> could define it's own generic, and one would want to be informed
   MM> of the
   MM> collision.

This shouldn't be a problem because generics keep track of the function
and package used.

setGeneric(plot)
str(getGeneric(plot))

   MM>
   MM> Maintenance of packages that have used simple 'import' to pull
   MM> in all
   MM> dependencies is tedious, but using 'import' in some ways
   MM> undermines
   MM> benefits of name spaces (restricting the symbol lookup table
   MM> to reduce
   MM> the number of symbols and the possibility of name collisions,
   MM> and to
   MM> more carefully isolate code inside the package name space to
   MM> changes in
   MM> imported packages or induced by the user). So I think a 'better
   MM> practice' is to explicitly import just those functions,
   MM> classes, etc
   MM> that are required by the package. Maintenance of such selective
   MM> imports
   MM> is much less tedious, even with complicated package
   MM> dependencies. There
   MM> is an unreleased Bioconductor package to identify specific
   MM> imports,
   MM> available for R-2.9.* at


I agree with you that 'importFrom' should be the preferred approach. I
have been using it for some time and I have even wrote my own
functions to automatically generate the NAMESPACE. 


But the drawback is that it makes the dependency with other packages
version specific and can become tricky when one has several such
dependencies.

To make the maintenance of packages easier, I would like to use
the suboptimal 'import' so that I do not need to care about this
NAMESPACE/package version issue. But I cannot do that because of an,
IMO, unjustified warning.

regards,
Yohan

-- 
PhD student
Swiss Federal Institute of Technology
Zurich

www.ethz.ch



More information about the R-devel mailing list