Thomas, On May 31, 2011, at 2:16 PM, Thomas Friedrichsmeier wrote:
> On Tuesday 31 May 2011, [email protected] wrote: >> Also note at the beginning of of th help file: >> >> Utility functions to access and replace the non-exported functions >> in a name space, for use in developing packages with name spaces. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This is intended only as a developer convenience, not as something to >> be used in production code. It is quite deliberate the name spaces are >> intended to be read-only once created. This allows the compiler to >> make assumptions about functions/constants defined in a name space. >> For now the compiler only uses this infomation for the base packages, >> but that could change in the future. > > Could you elaborate a bit? In RKWard, we do make use of assignInNamespace(), > mostly in order to insert hooks into functions where there are none by > default. For example, in order to get correct interleaving of output > generated > by system() commands, and R output, we insert two calls for synchronization > inside base::system() and base::system2(). As another example, we add some > code into utils::select.list() to provide our own UI if graphics=TRUE. In > total, currently, we have around a dozen calls to assignInNamespace(), for > which I do not see any workable alternative. > > None of these changes the function formals, environment, or type of return > value. All of this is done only once, at the start of the session. Should I > be > worried that it will still interact badly with the compiler? > I would expect so, but I'll let Luke comment on it. It is definitely a very bad idea. R provides facilities for customization and other GUIs are using them properly. If you are lacking anything, I would suggest asking here first - it is much easier to add a useful customization path to R than to deal with hacks that are fragile due to unjustified assumptions. As a user, I'm really worried about packages modifying other packages behind my back (but I may be more paranoid than others). Cheers, Simon ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
