[Rd] assignInNamespace and new bindings

Simon Urbanek simon.urbanek at r-project.org
Tue May 31 20:54:34 CEST 2011


Thomas,

On May 31, 2011, at 2:16 PM, Thomas Friedrichsmeier wrote:

> On Tuesday 31 May 2011, luke-tierney at uiowa.edu 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



More information about the R-devel mailing list