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