On Mon, Mar 3, 2014 at 2:50 PM, Simon Urbanek
<simon.urba...@r-project.org>wrote:
> Jens,
>
> On Mar 3, 2014, at 3:35 PM, Jens Oehlschlägel <
> jens.oehlschlae...@truecluster.com> wrote:
>
> >
> > Well, I did read, for example "Writing R Extensions" (Version 3.1.0
> Under development (2014-02-28)) chapter "5.9.10 Named objects and copying"
> which says "Currently all arguments to a .Call call will have NAMED set to
> 2, and so users must assume that they need to be duplicated before
> alteration."
>
> Matthew pointed out that line and I cannot shed more light on it, since
> it's not true - at least not currently.
>
>
> > This is consistent with the observation of my test code: that NAMED() in
> .Call always returns 2.
>
> It is not - you're not testing .Call() - your'e testing the assignments in
> frames which cause additional bumps of NAMED. If you actually test .Call()
> you'll see what I have reported - .Call() itself does NOT affect NAMED.
>
>
I think that's what R-ext is saying. The context is assignment functions,
and the section is explaining that while you might think you can write
assignment functions with .Call() that modify their arguments, by the time
the object gets into .Call() it will have NAMED==2 because there's the
object you're trying to modify and the reference to it inside the
assignment function.
If you write assignment functions that way, you need to make potentially
unsafe assumptions. For example, that you can't get an error halfway up a
chain of nested complex assignments when it's too late to back out of the
expression.
-thomas
--
Thomas Lumley
Professor of Biostatistics
University of Auckland
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
