Konrad Rudolph

> When the autoreload flag is set, all modules get replaced by "module wrappers" which always check for modifications and reload if necessary before providing access to an object. Ah,...

@GitHunter0 The auto-reload mechanism that’s currently under development provides a better, more comprehensive solution. You can check the progress and discussion here: #246.

Unfortunately I don’t hink this is fixable, even in principle, except in very limited cases. There’s simply no way to distinguish between the user rerunning an “existing” `box::use` expression on...

Is there a need to switch between the two semantics? Isn’t (ii) *always* what the user wants? I know that ‘box’ currently isn’t doing this, but moving to (ii) is...

Ah, hm. I actually thought of a case. Consider the following. ```r box::use(a[...]) box::use(b[...]) box::use(a[f]) ``` Assume that both `a` and `b` export two functions, `f` and `g`. Whether we...

Just a quick note that I’ve seen this question but I don’t have an answer ready. Just briefly: *For now* I would prefer not stuffing the package with too many...

Closely related: how to test module internals (i.e. non-exported functionality)? Originally asked in #221 by @aniaskrzydlo.

There are two aspects here: 1. `box::use` keeps the module source when loading, so debugging in modules loaded via `box::use` works in RStudio. What unfortunately *doesn’t* work is setting break...

> Is there any other way to step through code that you know does work with `box`? ‘box’ itself doesn’t interfere with R’s built-in debugging mechanisms. Therefore, all the following...

On a philosophical level, the package author (i.e., me) sees modules as a *successor* and *replacement* of packages. So, rather than migrating code from modules into packages, code should be...