[Rd] Defining a method in two packages

[Douglas Bates]

I think a simpler solution, which I have implemented in lme4 but not
yet released is to have

importFrom(nlme, ranef, fixef)

in the NAMESPACE file of packages that implement methods for those
generics (and, of course, add nlme to the Imports: specification in
the DESCRIPTION file).  As nlme is a required package I don't think
this is too much of a burden.

On Tue, Mar 9, 2010 at 8:52 PM, Kevin Coombes <kevin.r.coombes at gmail.com> wrote:
> Wouldn't it make sense to simply create a "ranef" package whose only role in
> the universe is to create the generic function that lme4, coxme, and anyone
> else who needs it could just import, without getting tons of additional and
> (depending on the application) irrelevant code?
>
> Best,
>   Kevin
>
> Uwe Ligges wrote:
>>
>>
>> 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
>