Dear developers, I maintain a package, emmeans, that provides post-hoc analyses for a variety of models. These models are supported by writing S3 methods for recover_data and emm_grid. Quite a few models are supported internally in emmeans, but it would really be better if the packages that create model objects would have their own implementations of these methods.
For example, a hypothetical package, foopkg may be used to fit a model, thereby producing an object of class foo. Currently, emmeans has internal functions recover_data.foo and emm_basis.foo (typically not exported). It would be better if the developer of foopkg would incorporate and export her own recover_data.foo and emm_basis.foo methods, so that those methods can be modified as needed as foopkg is further developed. Once those methods are incorporated in foopkg, then I would remove them from my next update of emmeans. But while they are available in both places, the ones in foopkg should be used. The problem is that in the short term, recover_data.foo and emm_basis.foo are still present in the namespace of emmeans. And I have found in testing with a fake package that if the user codes, say, emmeans::emmeans(model.foo, "treatment"), the methods internal to emmeans's namespace are always used even when foopkg is attached and its recover_data and emm_basis methods are registered. So the developer of foopkg can't even test her own methods (except by changing the class name of the model object). What can be done to facilitate having another developer's methods to override your own? Thanks for any advice Russ Russell V. Lenth - Professor Emeritus Department of Statistics and Actuarial Science The University of Iowa - Iowa City, IA 52242 USA Voice (319)335-0712 (Dept. office) - FAX (319)335-3017 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
