[Rd] Defining a method in two packages

Uwe Ligges ligges at statistik.tu-dortmund.de
Tue Mar 9 16:19:30 CET 2010

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,

> Terry

More information about the R-devel mailing list