[Rd] S4 Generics and NAMESPACE : justified warning ?

[Martin Maechler]

>>>>> "YC" == Yohan Chalabi <chalabi at phys.ethz.ch>
>>>>>     on Fri, 28 Aug 2009 16:24:29 +0200 writes:

    >>>>> "MM" == Martin Morgan <mtmorgan at 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