[R] redefining core functionality (was: new sep argument for interaction)

[Gabor Grothendieck]

Martin Maechler <maechler <at> stat.math.ethz.ch> writes:

> I apologize to Frank, but the fact that 'Hmisc' redefines
> standard R functions {the "[.factor" redefinition being much

I was thinking about this too, although not initially in relation to 
Hmisc, as I recently posted a function called rbind.case, see

https://www.stat.math.ethz.ch/pipermail/r-help/2004-August/053993.html

in which I redefined cbind.   In that case the redefinition was
within another function so its scope was limited to the internals
of that function.  Also the redefinition is used so its use was
close to its definition, in fact in the very next line, so it seemed 
harmless and it does convey the idea of what the function is supposed 
to do. In that case, I guess I could have just as easily called it cbind2, 
which would have conveyed the idea that it's a cbind-like function 
yet eliminate any confusion at all.

In the case of a function exported from a package, the situation is
potentially less benign since it couples all code that uses that 
function to the package even if the invoking code has nothing to do 
with that package.

I see several problems and benefits with redefinitions.  First
the problems:

- If the redefinition _is_ backwardly compatible (just adds a parameter 
like interaction does) then its normally not a problem; however, if 
there were a bug in the redefinition then that bug potentially propogates 
to all functions in your workspace that use the function being redefined, 
even if they have nothing to do with the package in question.

- If the redefinition is _not_ backwardly compatible it may break code
not related to the package just by loading the package, even if such
code is otherwise independent of the package.

On the other head, I can see why one would want to do it:

- we often see exhortations on the list to users to develop their own code
rather than rely on the core group and if you want R to work in the way 
you like what better way then to redefine it in a package so that it 
does.  If, in particular, if you are hoping that such functionality 
ultimately gets included in the core then it seems like a natural 
progression to use the same name so that if/when it does happen you can 
continue to use the exact same code. (Returning to Hmisc, for the
moment, that is precisely the case with interaction where Frank
put in sep=, as well as left= by the way, and now at least sep=
is migrating the core.  Perhaps left= should be added too so that
interaction can be removed from Hmisc.   Also perhaps other
functionality in Hmisc that do redefinitions could be identified
and considered for possible movement to the core and, of course,
this potentially applies to other packages, too.)

- Also, from a practical viewpoint, using R's S3 class structure one 
cannot define factor2, say, to be a subclass of factor inheriting all its 
methods except for those overridden.  Thus if you want to change the
behavior of factors or other S3 classes you either have to provide 
interfaces to every factor method for your new factor2 class or you 
do the more expedient thing of just redefining the one method in factor 
that you want redefined.