[Rd] multiple defines of diag

[Kasper Daniel Hansen]

Terry,

if you're using two packages that both define a diag function/method
you absolutely _have_ to resolve this using your NAMESPACE.  [Update:
I see both are methods.  I actually don't know what happens when you
have the same generic in both packages]

And yes, there is both an importClassesFrom and importMethodsFrom.

Since import() grabs everything you need to selectively import
functions/methods/classes from at least one of the two packages.  I
have been in the same situation, and it is painful to figure out all
the stuff you need from the package you selectively import.  A while
ago I suggested having something like
  importExcept
to selectively exclude specific functions when you have a name clash,
but I don't think anyone took up my suggestion.

Kasper

On Thu, Oct 6, 2011 at 8:06 AM, Terry Therneau <therneau at mayo.edu> wrote:
> The current coxme code has functions that depend on bdsmatrix and others
> that depend on Matrix, both those pacakges define S4 methods for diag.
> When loaded, the message appears:
>   replacing previous import ‘diag’ when loading ‘Matrix’
>
> Questions:
>  1. Do I need to worry about this?  If so, what can I do about it?
> I suppose I could add an importFrom directive, but it will be a pain
> unless there is an "allbut(diag)" option I'm not aware of.  (I assume
> that methods and classes can be listed in importFrom, i.e., there are no
> importMethodsFrom or importClassesFrom functions).
>
>  2. If I don't need to worry, is there a way to turn the message off?
> I as a developer need to see it, but users don't and it may worry them
> unnecessarily.  Updating all 17 of my test/*.Rout.save files is a
> nuisance as well, but only a nuisance.
>
> I'd like to upload this to CRAN soon as I have users asking for the
> updated lmekin function (which uses Matrix).  In the long term all the
> bdsmatrix functions will be replaced by Matrix, but that requires major
> changes to C code so "long" is the operative word.
>
> Thanks,
>  Terry T.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>