Defining a method in two packages

On 08.03.2010 17:16, Terry Therneau wrote:

Brian&  Uwe,
   Thanks for responding.  Let me see if I can refine the query and move
towards a solution.

From Uwe:
Of course, after loading lme4, you can still use the ranef from coxme:
coxme::ranef(fit)

Of course, but I'm interested in other users (as well as myself) and
prefer to avoid the 'secret handshake' form of a call.

In your own package, you could simply import the generic from coxme.

I don't understand this.

You could import the generic from the other package and define your 
won methods for it in order to make dispatching work correctly.

From Brian:
My solution would though be NOT to reuse a name that is already
established in another package (nlme has used it for many years).
The design problem is that generic foo() in package B might have
nothing to do with foo() in package A.  When it does, we expect B ...

I disagree completely.  It is precisely because of nlme and lmer
prominence that I want to reprise their methods: my users have a much
better chance of remembering how to do things.  If I followed this logic
to its conclusion one should never define a print() method because it
might conflict with the base definition.
   The consequence is that I am under obligation to NOT make my method
something different than Doug's, if I want to satisfy the goal of user
level consistency.  Several aspects of coxme purposefully mimic lmer,
even in cases (such as print.coxme) where his layout is not precisely
what I would have chosen.

Then please folow my suggestion and import the generic from the 
packages mentioned above in your namespace. Then you could extend it 
by your own methods wihtout having to define another generic of the 
same name and avoid the conflicts.

   I really do not want to require lme4 just to pick up the methods
definition.  It's a huge package, and there is no code in common.  Both
packages work very hard to be efficient via sparse matrix methods, but
the actual details are completely different due to the mathematical
structure of our underlying likelihoods.  Use of both in the same
analysis would be rare, so my issue won't be common.

Well, then things become complicated if not impossible.

The situation can be alleviated by making S3 methods visible.  Thus if
coxme exported coxme:::ranef.coxme and lme4 had a default method

ranef<- function (object, ...) UseMethod("ranef")

  I have no objection to exporting my method.  If a joint change to lme4
and coxme is the best solution, I will take the discussion off line with
Doug.  Is this the best way forward?

I think so.

Best wishes,
uwe

Terry