Re: [O] [PATCH] read.table in variable transfer caused sometimes "function not found" error - small change

[Rainer M Krug]

"Charles C. Berry" <address@hidden> writes:

> On Mon, 6 Oct 2014, Rainer M Krug wrote:
>
>> Hi
>>
>> The variable transfer of tables from org to R caused sometimes 'could
>> not find function "read.table"' errors (e.g. when the file was tangled
>> into a ./data directory which was loaded by the function
>> devtools::load_all("./")). This can easily be fixed by adding the package
>> name to the call in R, i.e. replacing =read.table()= with
>> =utils::read.table()= which is done in this patch.
>
> It does fix that one case.
>
> But I wonder if that is the best way.
>
> The heart of the matter is that load_all eventually calls sys.source,
> which can be persnickety about finding objects on the search path. See
> ?sys.source.
>
> If the src block you tangle to ./data/ has any code that uses any
> other objects from utils, stats, datasets or whatever, you will be in
> the same pickle.

Exactly - that is true. But it is the same when putting this in a
package (as far as I am aware).

>
> Arguably, this is a bug in devtools::load_data. And maybe it would be
> better to beg the maintainer for a fix or an extension that
> accomodates your case.

I don't know - As far as I understand, it is the same behaviour as if it
would be loaded from a package - i.e. =library()= so it would not be a
bug but it emulates the behaviour of library(), which it should.

>
>>
>> In R the calls read.table and utils::read.table are interchangeable (the
>> second one is actually preferred) so no negative effects can be
>> expected.
>
> What if the user has intentionally masked read.table or the eventual
> package provides its own read.table?

I would not go there - I see the variable as a mechanism similar to the
call to library() in R, which should behave absolutely equal everywhere,
even if functions are re-defined. If one wants to have a non standard
behaviour in this step, one could always re-define the way variables are
transferred, or, the better approach, do it afterwards.

So I think the use of =utils::read.table()= is preferable to the risky
use of only =read.table=, exactly because of the re-definition issue you
raise.

So I would opt to apply this patch as it makes the variable transfer
more stable.

Cheers,

Rainer 

>
> HTH,
>
> Chuck
>
>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

pgp0GfTb9zZUE.pgp
Description: PGP signature