>>>>> "YC" == Yohan Chalabi <chal...@phys.ethz.ch>
>>>>> on Fri, 28 Aug 2009 16:24:29 +0200 writes:
>>>>> "MM" == Martin Morgan <mtmor...@fhcrc.org>
>>>>> on Tue, 18 Aug 2009 06:15:50 -0700
YC> Hi Martin,
YC> Thanks for your response.
MM> Commenting as a user, there's no guarantee that the
MM> 'plot' generic defined in pkgA is derived from
MM> graphics::plot via setGeneric; pkgA could define it's
MM> own generic, and one would want to be informed of the
MM> collision.
YC> This shouldn't be a problem because generics keep track of the function
YC> and package used.
YC> setGeneric(plot)
YC> str(getGeneric(plot))
yes, but you (Yohan) have provided a patch proposal which made
the warning go away in this one case, and
IIUC Martin Morgan argued that the warning was still needed because
of his case above.
MM> Maintenance of packages that have used simple 'import'
MM> to pull in all dependencies is tedious, but using
MM> 'import' in some ways undermines benefits of name
MM> spaces (restricting the symbol lookup table to reduce
MM> the number of symbols and the possibility of name
MM> collisions, and to more carefully isolate code inside
MM> the package name space to changes in imported packages
MM> or induced by the user). So I think a 'better practice'
MM> is to explicitly import just those functions, classes,
MM> etc that are required by the package. Maintenance of
MM> such selective imports is much less tedious, even with
MM> complicated package dependencies. There is an
MM> unreleased Bioconductor package to identify specific
MM> imports, available for R-2.9.* at
MM> [...............]
YC> I agree with you that 'importFrom' should be the preferred approach. I
YC> have been using it for some time and I have even wrote my own
YC> functions to automatically generate the NAMESPACE.
YC> But the drawback is that it makes the dependency with other packages
YC> version specific and can become tricky when one has several such
YC> dependencies.
Yes.
YC> To make the maintenance of packages easier, I would like to use
YC> the suboptimal 'import' so that I do not need to care about this
YC> NAMESPACE/package version issue. But I cannot do that because of an,
YC> IMO, unjustified warning.
Yes, I agree, unjustified in your case.
The question is: is there a patch which does differentiate
between your situation and Martin's scenario -- or does your
patch already do that?
Regards,
Martin Maechler, ETH Zurich
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
