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.
>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.
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.
> 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?
Terry
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
