Re: [Rd] Defining a method in two packages

From: Uwe Ligges <ligges_at_statistik.tu-dortmund.de>
Date: Tue, 09 Mar 2010 16:19:30 +0100

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
>
>
>
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 09 Mar 2010 - 15:25:32 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 10 Mar 2010 - 13:41:01 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive