Re: [Rd] assignInNamespace and new bindings

From: Simon Urbanek <simon.urbanek_at_r-project.org>
Date: Tue, 31 May 2011 14:54:34 -0400

Thomas,

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

> On Tuesday 31 May 2011, luke-tierney@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



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 31 May 2011 - 18:56:17 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 31 May 2011 - 21:00:16 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive