[Rd] Overwriting imported function in another package

Joshua Wiley jwiley.psych at gmail.com
Tue Aug 9 07:11:27 CEST 2011

> [Jeroen Ooms wrote:]
>> > I am running into a limitation of the grid::grid.newpage function, for which I would like to overwrite this function
>> > with a slightly modified one. Hopefully this is a temporary working solution until the package gets updated. I found a
>> > way to overwrite the function in the package:grid namespace. However, lattice imports grid rather than depending on it.
>> > So I need a way to overwrite this imported version as well. The code below shows the fix which works for ggplot (because
>> > it depends on grid), but it doesn't work for lattice, because it imports grid. Is there any way to overwrite
>> > grid.newpage for all instantiations of it?
> [Duncan Murdoch wrote:]
>> But everyone who uses your code has a right to expect that other
>> packages are not affected by it.

<Mark.Bravington at csiro.au> wrote:
> One should of course only do such things reluctantly and responsibly, as Duncan points out; any changes shouldn't modify *expectable* behaviour of existing functions! But if it's just a bug-fix or innocuous extension of functionality, and/or just in one's own work, then I can see two approaches that might help.

As a user, I would be strongly opposed to this, even for "buggy" code.

> Second: *after* loading the offending package, (e.g. in the '.onLoad' of your own package, if you're putting this into a package) you could use 'fun.locator' in 'mvbutils' to find all instances of the offending function including imports, and then change each copy manually. An example is 'mtrace' in 'debug', which deliberately tries to find and change all copies of a function. (Whether 'fun.locator' finds absolutely every copy, I'm not sure, but it does try; NB it won't work as-is for S4, and needs to be used differently for ref classes.) This is uglier, but should be automatic (and should also ensure that any subsequent imports of the offender pick up the patched version, though I haven't checked).
> Note that this won't work retrospectively for copies that are imported into a package namespace under an alias, which I think used to be a theoretical possibility but may not be any more.

This strikes me as essentially as a package that, when
installed/loaded "infects" other packages and software.  R and CRAN
are open source.  If you need something different than what you have,
make something different.  You could make: JOsggplot2, JOslattice,
etc. and have your package depend on those.  User's do not need to
compile from source, and rather than hijacking other packages, it is
clear that a package similar to but different from ggplot2 and lattice
is being used.


More information about the R-devel mailing list