LSH和RSH
-
我们在对变量-函数等进行赋值的时候的时候 会发生以下场景:
-
引擎会为变量a 进行LHS 查询。另外一个查找的类型叫作RHS。
我打赌你一定能猜到“L”和“R”的含义,它们分别代表左侧和右侧。
什么东西的左侧和右侧?是一个赋值操作的左侧和右侧。
换句话说,当变量出现在赋值操作的左侧时进行LHS 查询,出现在右侧时进行RHS 查询。 -
讲得更准确一点:
-
RHS 查询与简单地查找某个变量的值别无二致,而LHS 查询则是试图
找到变量的容器本身,从而可以对其赋值。从这个角度说,RHS 并不是真正意义上的“赋
值操作的右侧”,更准确地说是“非左侧”。
你可以将RHS 理解成retrieve his source value(取到它的源值),这意味着“得到某某的
值”。
让我们继续深入研究。
考虑以下代码:
console.log( a );
-
其中对a 的引用是一个RHS 引用,因为这里a 并没有赋予任何值。相应地,需要查找并取
得a 的值,这样才能将值传递给console.log(…)。
相比之下,例如:a = 2;
-
这里对a 的引用则是LHS 引用,因为实际上我们并不关心当前的值是什么,只是想要为=
2 这个赋值操作找到一个目标。
LHS 和RHS 的含义是“赋值操作的左侧或右侧”并不一定意味着就是“=
赋值操作符的左侧或右侧”。赋值操作还有其他几种形式,因此在概念上最
好将其理解为“赋值操作的目标是谁(LHS)”以及“谁是赋值操作的源头
(RHS)”。
考虑下面的程序,其中既有LHS 也有RHS 引用:
function foo(a) {
console.log( a ); // 2
}
foo( 2 );
-
最后一行foo(…) 函数的调用需要对foo 进行RHS 引用,意味着“去找到foo 的值,并把
它给我”。并且(…) 意味着foo 的值需要被执行,因此它最好真的是一个函数类型的值!
这里还有一个容易被忽略却非常重要的细节。 -
代码中隐式的a=2 操作可能很容易被你忽略掉。这个操作发生在2 被当作参数传递给
foo(…) 函数时,2 会被分配给参数a。为了给参数a(隐式地)分配值,需要进行一次
LHS 查询。 -
这里还有对a 进行的RHS 引用, 并且将得到的值传给了console.log(…)。console.
log(…) 本身也需要一个引用才能执行,因此会对console 对象进行RHS 查询,并且检查
得到的值中是否有一个叫作log 的方法。
最后,在概念上可以理解为在LHS 和RHS 之间通过对值2 进行交互来将其传递进log(…)
(通过变量a 的RHS 查询)。假设在log(…) 函数的原生实现中它可以接受参数,在将2 赋
值给其中第一个(也许叫作arg1)参数之前,这个参数需要进行LHS 引用查询。
- 你可能会倾向于将函数声明function foo(a) {… 概念化为普通的变量声明
和赋值,比如var foo、foo = function(a) {…。如果这样理解的话,这
个函数声明将需要进行LHS 查询。
然而还有一个重要的细微差别,编译器可以在代码生成的同时处理声明和值
的定义,比如在引擎执行代码时,并不会有线程专门用来将一个函数值“分
配给”foo。因此,将函数声明理解成前面讨论的LHS 查询和赋值的形式并
不合适。