[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