From simon.urbanek at r-project.org  Sat Feb  8 16:44:21 2014
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Sat, 8 Feb 2014 10:44:21 -0500
Subject: [Rd] Redefining .Call
In-Reply-To: <CABtg=K=bj7fSrR04=0ujACwV59T1H-L48JfRbiXKhFaTynPq+g@mail.gmail.com>
References: <CABtg=K=bj7fSrR04=0ujACwV59T1H-L48JfRbiXKhFaTynPq+g@mail.gmail.com>
Message-ID: <B230B0A8-60CD-48DA-A540-259BDF93070F@r-project.org>

G?bor,

On Feb 8, 2014, at 10:19 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:

> Hi All,
> 
> is there a caveat in redefining .Call in a package? (Apart from the
> performance hit of the extra function call.)
> 

Why don't you just do s/\.Call/myCall/g in R/* instead? That would be a bit less dangerous in case you forget about it or need to use .Call in some cases.


> I want to execute a check every time I call back to C, and this seems to be
> the easiest solution, instead of modifying all functions of the package. It
> also seems to be a good way to supply the PACKAGE argument, btw.
> 

Ideally, you should not be using PACKAGE in the first place - it's mostly for backwards compatibility. Modern packages should be using cached symbols created by useDynLib() since they are much faster than looking up symbols for every call which unnecessary and  slow.

Cheers,
Simon


> I guess this is a good solution, but I might have overlooked something.
> 
> Thanks,
> Gabor
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 



[Rd] Redefining .Call
Simon Urbanek