Better approach for mocking base functions

[hadley]

It just occurred to me that you only need a binding, not a specific implementation. So this makes mocking base functions a little bit easier.

[jennybc]

I don't have a strong opinion here.

But this did remind me of some unpleasantness when usethis had an internal helper that masked a base R function, i.e. this whole saga:

rstudio/rstudio#8031

I also think this would mean that, after load_all(), a call to said base function would also not work for interactive development-time tinkering or in the debugger.

None of these concerns seem like a huge deal. But the potential for creating puzzles or obstacles for yourself makes me think that, if you need to mock something, it's probably best to just wrap it and keep everything nice and obvious.

[hadley]

I don't think it will interfere with your use of said functions because interative() will ignore non-function objects in the search path. So it might only be confusing if you type interactive.

[lionel-]

Makes sense!

The other thing we could do, when we detect the user wants to mock a base function, is to insert an unlocked environment between imports and base? This way users wouldn't need to think about the difference between imported functions (which are bound in an environment private to the package) and base functions (which are shared across all packages).

[hadley]

@lionel- yeah, that might be worth considering, although I'm not sure if modifying parent.env() is much better than (e.g.) calling rlang::env_unlock() on the package env.