为什么使用分配不好？

Question

这篇文章 (Lazy evaluation in R – is assign affected?) 涵盖了一些共同点，但我不确定它是否能回答我的问题。

当我很久以前发现apply 家族时，我停止使用assign，尽管纯粹是出于在这种情况下优雅的原因：

names.foo <- letters
values.foo <- LETTERS
for (i in 1:length(names.foo))
  assign(names.foo[i], paste("This is: ", values.foo[i]))

可以替换为：

foo <- lapply(X=values.foo, FUN=function (k) paste("This is :", k))
names(foo) <- names.foo

这也是这个 (http://cran.r-project.org/doc/FAQ/R-FAQ.html#How-can-I-turn-a-string-into-a-variable_003f) R-faq 说应该避免这种情况的原因。

现在，我知道assign 通常不受欢迎。但是还有其他我不知道的原因吗？我怀疑它可能会影响范围界定或惰性评估，但我不确定？演示此类问题的示例代码会很棒。

Answer 1

实际上这两个操作是完全不同的。第一个给你 26 个不同的对象，而第二个给你一个。第二个对象将更容易在分析中使用。所以我想我会说你已经证明了assign 的主要缺点，即必须始终使用get 来收集或收集所有名称相似的单个对象，这些对象现在在全局中“松散”环境。试着想象一下你将如何对这 26 个独立的对象进行连续的处理。对于第二种策略，一个简单的lapply(foo, func) 就足够了。

FAQ 引用实际上只是说使用分配然后分配名称更容易，但并不意味着它是“坏的”。我碰巧将它读作“功能较少”，因为您实际上并没有返回一个被分配的值。该效果看起来是一种副作用（在这种情况下，assign 策略会产生 26 个单独的副作用）。 assign 的使用似乎被来自具有全局变量的语言的人采用，作为避免采用“真正的 R 方式”的一种方式，即使用数据对象进行函数式编程。他们真的应该学习使用列表，而不是在他们的工作空间中乱扔单独命名的项目。

还有另一种可以使用的赋值范式：

 foo <- setNames(  paste0(letters,1:26),  LETTERS)

这会创建一个命名原子向量而不是命名列表，但对向量中值的访问仍然是使用给[ 的名称完成的。

Answer 2

作为fortune(236) 的来源，我想我会添加几个示例（另请参阅fortune(174)）。

首先，一个测验。考虑以下代码：

x <- 1
y <- some.function.that.uses.assign(rnorm(100))

运行上面2行代码后，x的值是多少？

assign 函数用于提交“远距离操作”（参见http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming) 或谷歌）。这通常是难以找到错误的根源。

我认为assign 的最大问题是它往往会引导人们走上思考的道路，从而使他们远离更好的选择。一个简单的例子是问题中的 2 组代码。 lapply 解决方案更优雅，应该推广，但人们了解assign 函数这一事实将人们引向循环选项。然后他们决定他们需要对循环中创建的每个对象执行相同的操作（如果使用了优雅的解决方案，这将只是另一个简单的lapply 或sapply）并求助于一个更复杂的循环，同时涉及@ 987654332@ 和 apply 以及对 paste 的丑陋电话。然后那些迷恋assign 的人会尝试做类似的事情：

curname <- paste('myvector[', i, ']')
assign(curname, i)

这并没有达到他们的预期，这导致要么抱怨 R（这就像抱怨我隔壁邻居的房子太远，因为我选择绕着街区走很长的路一样公平）甚至更糟糕的是，深入研究使用eval 和parse 让他们构造的字符串“工作”（然后导致fortune(106) 和fortune(181)）。

Answer 3

我想指出，assign 旨在与environments 一起使用。

从这个角度来看，上面示例中的“坏”事情是使用了不太合适的数据结构（基本环境而不是list 或data.frame、vector，...）。

旁注：对于environments，$ 和$<- 运算符也有效，因此在许多情况下，显式的assign 和get 也不是必需的。