> In regard to "should", I think it is a > very very bad idea. > > The result that someone gets depends on > whether or not the new package is attached > in the session. That is a recipe for hours > (or days) of trying to figure out mysterious > behavior.
I fully agree. However, there are 2 reasons in this particular case, why I decided nevertheless to be "evil": 1. The package will never (well, never say never, but from today's point of view I see no reason, why this should ever happen) be published and is intended for internal use only. 2. Even more important: I think that 'droplevels' in the base package has a major flaw as it silently drops any contrast chosen by the user. Hence, a user who wants to use droplevels, has to reassign all contrasts afterwards. In another discussion it was pointed out, that contrasts which worked fine for a factor, may be erroneous once a level is dropped (in the case we specify the contrasts matrix directly). I acknowledge this case (and so does my function as it falls back to the base version but issues a warning), yet I think for all the other cases, where the contrast is defined via a function, it would be the better behaviour to use the same contrast function rather than dropping it silently. As a consequence, I think that my function does no harm, for it does exactly the same as the base function while adding more functionality. Thus, even if the user is used to the annoying behaviour of base::droplevels and reassigns the contrast after each use of droplevels, he will see no difference whether or not my package is loaded. In the former case the step is however not necessary. For the "how" part, I find out that I have to explicitly export my functions such that they can override the ones from the base package. Thus the solution was to add export(droplevels.factor, droplevels.data.frame) to my NAMESPACE file. Thanks for your input, -Thorn ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel