- 浏览: 961375 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
sscsacdsadcsd:
mike8625 写道react还要自己的一些标签 还得编译 ...
对于React体系的一点想法 -
mike8625:
说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话 ...
关于国内前端和JS技术发展的乱想 -
mike8625:
react还要自己的一些标签 还得编译 编译吧浏览器端说还慢 ...
对于React体系的一点想法 -
u012814086:
下意识想到了Golang
JavaScript语句后应该加分号么? -
xueduanyang:
我是水羊,年轻的时候觉得只要有好斧子就能做成好产品,各种产品都 ...
关于国内前端和JS技术发展的乱想
原讨论帖地址是http://www.iteye.com/topic/101506
首先,这一个帖子中,Lich_Ray按照ECMA规范来推导,这个尝试是好的,但是ECMAScript的规范是出了名的佶屈聱牙,所以不幸的,Lich_Ray同志也未幸免。。。
以上都ok。
实际上看到这里,你应该可以看出两个turnOn根本就指向的是同一个对象,即函数test。所以当然是相等的。不等才怪!
可惜的是,Lich同志不知道是没有细看源代码,还是实在按捺不住解说那个复杂的joined function object的冲动,就直接奔向这“只剩这一种可能了”。
很明显,如果两个函数对象(只剩这一种可能了)可以被 joined,它们就相等。那么根据提示,翻到 13.1.2 Joined Objects。
下面是函数对象可被 joined 的条件:
这两句话罗嗦死了,其实就四个字:“同生同死”——要求可被 joined 的对象们的属性要产生都产生,要删除都删除。现在以此条件看 test 函数,符合以上条件,可被 joined,于是 === 运算符返回 true。
注意,你所摘录的只是Joined Objects的行为,而不是Joined的条件!所以你的逻辑首先有问题,就是因果颠倒了。其次,如前所说,这里根本没有两个test,只有一个test,然后有若干个对test的引用。
解决下一个问题,你曾经写过的返回 false 的代码:
前面步骤相同不用看了,只看最后一个步骤,
函数们能否被 joined?当然不能,用肚脐眼都能看地很清楚,修改 lightA.turnOn 上的属性不会影响 lightB.turnOn。
这里是你本篇的最大错误。“修改lightA.turnOn的属性不会影响lightB.turnOn“,这是因为它们是两个不同的对象,因而也不可能是被join的,但是这是结果,而不是原因!而且就算反推回去,也是不成立的。因为join只是可选的,并非强制的。
事实上,规范给出了一个可以join的例子如下(大意):
function A() {
function B(x) { return x*x }
return B
}
var a1 = A();
var a2 = A();
规范说:a1和a2是equate的,可以被join起来,并且因为他们的[[scope]]也没有可以观察到的差异,所以甚至可以指向same object,而不是两个被join起来的object。
首先我要指出,规范本身也不是完美的。就我本人来看,让a1和a2指向同一个对象,是很奇怪的一件事情。而且这个例子中,[[scope]]是没有差异的,更明确的说function B是不依赖A的。如果按照这个标准看, function () { alert("bingo"); }当然也是可以被指向同一个对象的!这实际上意味着lightA.turnOn和lightB.turnOn可以是同一个对象,因此你修改lightA.turnOn的属性,也就等于修改lightB.turnOn的属性。
这很奇怪,但是你不能因为奇怪就反推出他们不能join。BTW,你没有特异功能,所以你还是不要用肚脐眼来看代码。
进一步,在B依赖A的情况下,B也是可以join的。因为B依赖A,不过就是多个B的[[scope]]不同,而这是允许的(见13.1.2 Joined Object的NOTE部分)。
所以如果严格根据规范,implmentation选择join或者不选择join,实际上会导致差异,而且是语义上的差异。所以我认为这是规范的一个错误!!
当然,要确认这一点,我是不够权威的,我打算有空的时候,写个信求教一下BE。
事实上,我所知的所有实现,都没有像规范所描述的join行为。也就是规范所举的那个a1和a2,在现实我所实验过的任何一个引擎里,都是不==的。
问题解决完了,下面解释我提到过的函数相等性测试。第 13.1.1 节,Equated Grammar Productions 中的内容已经讲过,没看见拉倒。下面翻到课本:
这一节的算法中,用到函数相等性测试的只有 Step1
这一段话的意思很明显:如果函数相等性测试可用,就配合括号中的句子(If there is more than one object E satisfying these criteria, choose one at the implementation's discretion.)做优化;如果不可用,Step 1 忽略。
这里有一个隐含的内容:是否优化对语言语义无影响。这涉及编译原理的体系,即:优化措施属于实现层,实现层不可影响由语言规范所定义的语义层,即语言的外在表现。说白了,就是“规范是上帝,实现只能是上帝的羊羔,随你怎么折腾,不可僭越”,否则就是实现失败。所以我看到 keshin 这个第一帖中的代码时,想都不想就知道是语义的结果,跟实现无关。
如前所述,规范本身可能存在缺陷,导致语义可变。所以所有的实现都选择不join。
以 Rhino 解释器(也就是 Firefox 的解释器啦)为例,一个函数对象(JavaScript 中函数没有对应原始类型,就是(is a) Object)在解释器中由两部分构成:一是可执行的继承 Scriptable,Callable 接口的 Java 类 BaseFunction 对象,外部 wrap 是 FunctionObject 类的对象。相等性测试通过的函数们,都是堆上的一个 BaseFunction,被存储为一个 FunctionNode,作为 JavaScript 函数执行时只调用一段代码块;但执行 === 比较时,只比较其在 JavaScript 中的外在表现,即 FunctionObject 是否相等,结果就是这样有些“奇怪”的表现。
Rhino的具体实现,与Joined Object,是没有直接关系的。或者说,Rhino实现的其实是所有equated的函数都是一个BaseFunction对象。实际上,所有的现实js实现都会采取类似的策略。
特别的,我们在SpiderMonkey(就是FF等用的js引擎)中可以看到这种痕迹:
function A() {
return function() {}
}
你会发现,A().__proto__不等于Function.prototype(由于__proto__并没有说就是[[prototype]],所以也不能说spidermonkey不合规范)。
但是两次调用的结果是相同的。也就是 A().__proto__ == A().__proto__,并且A().__proto__.__proto__ == Function.prototype。
也就是说,SpiderMonkey会在每个function(设为X)里面预先产生一个共享的function(设为Y)。所有X里直接包含的function都会以Y作为__proto__,而这些不同的function对象,只有[[scope]]是不同的。这就是一种优化,而且很美妙的使用了js自己的prototype chain的机制。
Safari有__proto__属性,但是就没有上述现象(但是它仍可以在内部有一个类似的机制)。
讲解结束,下面是我对这个问题的个人意见。
我给出的代码,从效率角度来看,不是最优的;但从上文的叙述中可以看出,可以这样理解:
我的话说完了。请注意,下面不是答疑时间。
PS: 刚刚才看到 keshin 原帖新加的内容。ECMA 的人说的非常正确,不过他们不敢解释太多;态度很客气,这一点让我非常佩服。
最后,回复keshin的不知道是哪位。他所描述的也就是一个实现的一般思路。但是说到规范的本意,只有问当时的参与制定者才能了解。例如BE同志。
首先,这一个帖子中,Lich_Ray按照ECMA规范来推导,这个尝试是好的,但是ECMAScript的规范是出了名的佶屈聱牙,所以不幸的,Lich_Ray同志也未幸免。。。
Lich_Ray 写道
看来我就此开个 JavaScript 专栏一心和你们讨论这些问题算了。这帖子居然还有一群人跟在后面打“良好”“精华”,无语了…
火是要发的,问题也是要解决的。下面讲正经的。不仅仅讲给 keshin 一个人听,大家都来看下吧。我们开始从 === 运算符谈起。
请翻到 ECMA-262 e4 的 11.9.4 节,The Strict Equals Operator (===)。这里给出了 === 运算符的语法产生式和展开(注意,只是部分求值)步骤:
EqualityExpression === RelationalExpression is evaluated as follows:
它指出,对两个产生式的求值结果调用规范中的算法 GetValue(V)。那么翻到这一节,8.7.1 GetValue(V)。
根据第一句,判断 Type(V) 是不是引用。现在要分情况讨论一下。先解决你上一帖提出的问题。在你给出的构造函数中,需要执行的是这样一句:
那么,检查 Type(this.turnOn),是到一个 Object Type 的函数 test的引用。于是调用 GetBase(V) 获取到 trunOn 引用的基对象 this,此描述用函数的定义在 8.7 The Reference Type 中:
对象 this 不是 null,跳转第4步调用 8.6.2.1 节中 [[Get]](P) 算法,传递的属性名是 turnOn。根据算法
取到该属性的对应值,即内部记录的函数 test。现在我们知道了,是两个 test 在作比较。(友情提醒:请继续往下看。)那么返回 11.9.4 节。
现在只有 Step(5): Result(4) === Result(2). 是最重要的。旁边的(See below.)指出 === 的算法在下文,11.9.6 节 The Strict Equality Comparison Algorithm。在这一节我们看到了具体的算法。前面12步全是废话,看第13步:
[list=13] Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.
[/list]
火是要发的,问题也是要解决的。下面讲正经的。不仅仅讲给 keshin 一个人听,大家都来看下吧。我们开始从 === 运算符谈起。
请翻到 ECMA-262 e4 的 11.9.4 节,The Strict Equals Operator (===)。这里给出了 === 运算符的语法产生式和展开(注意,只是部分求值)步骤:
EqualityExpression === RelationalExpression is evaluated as follows:
- Evaluate EqualityExpression.
- Call GetValue(Result(1)).
- Evaluate RelationalExpression.
- Call GetValue(Result(3)).
- Perform the comparison Result(4) === Result(2). (See below.)
- Return Result(5).
它指出,对两个产生式的求值结果调用规范中的算法 GetValue(V)。那么翻到这一节,8.7.1 GetValue(V)。
- If Type(V) is not Reference, return V.
- Call GetBase(V).
- If Result(2) is null, throw a ReferenceError exception.
- Call the [[Get]] method of Result(2), passing GetPropertyName( V) for the property name.
- Return Result(4).
根据第一句,判断 Type(V) 是不是引用。现在要分情况讨论一下。先解决你上一帖提出的问题。在你给出的构造函数中,需要执行的是这样一句:
this.turnOn = test;
那么,检查 Type(this.turnOn),是到一个 Object Type 的函数 test的引用。于是调用 GetBase(V) 获取到 trunOn 引用的基对象 this,此描述用函数的定义在 8.7 The Reference Type 中:
- GetBase(V). Returns the base object component of the reference V.
对象 this 不是 null,跳转第4步调用 8.6.2.1 节中 [[Get]](P) 算法,传递的属性名是 turnOn。根据算法
- If O doesn't have a property with name P, go to step 4.
- Get the value of the property.
- Return Result(2).
- ...
取到该属性的对应值,即内部记录的函数 test。现在我们知道了,是两个 test 在作比较。(友情提醒:请继续往下看。)那么返回 11.9.4 节。
现在只有 Step(5): Result(4) === Result(2). 是最重要的。旁边的(See below.)指出 === 的算法在下文,11.9.6 节 The Strict Equality Comparison Algorithm。在这一节我们看到了具体的算法。前面12步全是废话,看第13步:
[list=13]
以上都ok。
实际上看到这里,你应该可以看出两个turnOn根本就指向的是同一个对象,即函数test。所以当然是相等的。不等才怪!
可惜的是,Lich同志不知道是没有细看源代码,还是实在按捺不住解说那个复杂的joined function object的冲动,就直接奔向这“只剩这一种可能了”。
Lich_Ray 写道
很明显,如果两个函数对象(只剩这一种可能了)可以被 joined,它们就相等。那么根据提示,翻到 13.1.2 Joined Objects。
下面是函数对象可被 joined 的条件:
- Any time a non-internal property of an object O is created or set, the corresponding property is immediately also created or set with the same value and attributes in all objects joined with O.
- Any time a non-internal property of an object O is deleted, the corresponding property is immediately also deleted in all objects joined with O.
- ...(这两句跟主题无关)
这两句话罗嗦死了,其实就四个字:“同生同死”——要求可被 joined 的对象们的属性要产生都产生,要删除都删除。现在以此条件看 test 函数,符合以上条件,可被 joined,于是 === 运算符返回 true。
注意,你所摘录的只是Joined Objects的行为,而不是Joined的条件!所以你的逻辑首先有问题,就是因果颠倒了。其次,如前所说,这里根本没有两个test,只有一个test,然后有若干个对test的引用。
Lich_Ray 写道
解决下一个问题,你曾经写过的返回 false 的代码:
function Light() { this.turnOn = function () { alert("bingo"); } } var lightA = new Light(); var lightB = new Light(); alert(lightA.turnOn === lightB.turnOn);
前面步骤相同不用看了,只看最后一个步骤,
function () { alert("bingo"); }
函数们能否被 joined?当然不能,用肚脐眼都能看地很清楚,修改 lightA.turnOn 上的属性不会影响 lightB.turnOn。
这里是你本篇的最大错误。“修改lightA.turnOn的属性不会影响lightB.turnOn“,这是因为它们是两个不同的对象,因而也不可能是被join的,但是这是结果,而不是原因!而且就算反推回去,也是不成立的。因为join只是可选的,并非强制的。
事实上,规范给出了一个可以join的例子如下(大意):
function A() {
function B(x) { return x*x }
return B
}
var a1 = A();
var a2 = A();
规范说:a1和a2是equate的,可以被join起来,并且因为他们的[[scope]]也没有可以观察到的差异,所以甚至可以指向same object,而不是两个被join起来的object。
首先我要指出,规范本身也不是完美的。就我本人来看,让a1和a2指向同一个对象,是很奇怪的一件事情。而且这个例子中,[[scope]]是没有差异的,更明确的说function B是不依赖A的。如果按照这个标准看, function () { alert("bingo"); }当然也是可以被指向同一个对象的!这实际上意味着lightA.turnOn和lightB.turnOn可以是同一个对象,因此你修改lightA.turnOn的属性,也就等于修改lightB.turnOn的属性。
这很奇怪,但是你不能因为奇怪就反推出他们不能join。BTW,你没有特异功能,所以你还是不要用肚脐眼来看代码。
进一步,在B依赖A的情况下,B也是可以join的。因为B依赖A,不过就是多个B的[[scope]]不同,而这是允许的(见13.1.2 Joined Object的NOTE部分)。
所以如果严格根据规范,implmentation选择join或者不选择join,实际上会导致差异,而且是语义上的差异。所以我认为这是规范的一个错误!!
当然,要确认这一点,我是不够权威的,我打算有空的时候,写个信求教一下BE。
事实上,我所知的所有实现,都没有像规范所描述的join行为。也就是规范所举的那个a1和a2,在现实我所实验过的任何一个引擎里,都是不==的。
Lich_Ray 写道
问题解决完了,下面解释我提到过的函数相等性测试。第 13.1.1 节,Equated Grammar Productions 中的内容已经讲过,没看见拉倒。下面翻到课本:
这一节的算法中,用到函数相等性测试的只有 Step1
- If there already exists an object E that was created by an earlier call to this section's algorithm, and if that call to this section's algorithm was given a FunctionBody that is equated to the FunctionBody given now, then go to step 13. (If there is more than one object E satisfying these criteria, choose one at the implementation's discretion.)
这一段话的意思很明显:如果函数相等性测试可用,就配合括号中的句子(If there is more than one object E satisfying these criteria, choose one at the implementation's discretion.)做优化;如果不可用,Step 1 忽略。
这里有一个隐含的内容:是否优化对语言语义无影响。这涉及编译原理的体系,即:优化措施属于实现层,实现层不可影响由语言规范所定义的语义层,即语言的外在表现。说白了,就是“规范是上帝,实现只能是上帝的羊羔,随你怎么折腾,不可僭越”,否则就是实现失败。所以我看到 keshin 这个第一帖中的代码时,想都不想就知道是语义的结果,跟实现无关。
如前所述,规范本身可能存在缺陷,导致语义可变。所以所有的实现都选择不join。
Lich_Ray 写道
以 Rhino 解释器(也就是 Firefox 的解释器啦)为例,一个函数对象(JavaScript 中函数没有对应原始类型,就是(is a) Object)在解释器中由两部分构成:一是可执行的继承 Scriptable,Callable 接口的 Java 类 BaseFunction 对象,外部 wrap 是 FunctionObject 类的对象。相等性测试通过的函数们,都是堆上的一个 BaseFunction,被存储为一个 FunctionNode,作为 JavaScript 函数执行时只调用一段代码块;但执行 === 比较时,只比较其在 JavaScript 中的外在表现,即 FunctionObject 是否相等,结果就是这样有些“奇怪”的表现。
Rhino的具体实现,与Joined Object,是没有直接关系的。或者说,Rhino实现的其实是所有equated的函数都是一个BaseFunction对象。实际上,所有的现实js实现都会采取类似的策略。
特别的,我们在SpiderMonkey(就是FF等用的js引擎)中可以看到这种痕迹:
function A() {
return function() {}
}
你会发现,A().__proto__不等于Function.prototype(由于__proto__并没有说就是[[prototype]],所以也不能说spidermonkey不合规范)。
但是两次调用的结果是相同的。也就是 A().__proto__ == A().__proto__,并且A().__proto__.__proto__ == Function.prototype。
也就是说,SpiderMonkey会在每个function(设为X)里面预先产生一个共享的function(设为Y)。所有X里直接包含的function都会以Y作为__proto__,而这些不同的function对象,只有[[scope]]是不同的。这就是一种优化,而且很美妙的使用了js自己的prototype chain的机制。
Safari有__proto__属性,但是就没有上述现象(但是它仍可以在内部有一个类似的机制)。
Lich_Ray 写道
讲解结束,下面是我对这个问题的个人意见。
我给出的代码,从效率角度来看,不是最优的;但从上文的叙述中可以看出,可以这样理解:
- 这可以作为一种不同于 prototype 的“新”的给对象绑定方法的形式,更加安全。对于这种观点和使用方式效率没有任何问题。
- 当作普通 prototype 的另一种写法来使用,相对于在代码中多消耗了一个 O(n) 级的算法,而且此算法来自 JavaScript 底层实现且可被加速,效率下降忽略不计,去掉 JS 代码中所有为空的行、无效空格,把所有换行换成 ; 损失就回来了;仅当处于“大规模的”循环中时才可视为一个 O(n) 算法,这种情况存在的可能性微乎其微,不过,还是那句话,尽量避免。
我的话说完了。请注意,下面不是答疑时间。
PS: 刚刚才看到 keshin 原帖新加的内容。ECMA 的人说的非常正确,不过他们不敢解释太多;态度很客气,这一点让我非常佩服。
最后,回复keshin的不知道是哪位。他所描述的也就是一个实现的一般思路。但是说到规范的本意,只有问当时的参与制定者才能了解。例如BE同志。
评论
3 楼
hax
2008-07-15
2007年8月6日更新(原帖地址:http://www.iteye.com/post/348743):
我发了邮件到es4-discuss邮件列表上(讨论ecmascript4的官方列表)。
有了一些讨论,我这里不一一复述。仅说一下大概。
经过一些讨论,大家都认为joined function是有问题的,主要的问题是可能导致语义不一致的情况出现。有人写了一个比我的例子更有力的例子:
function f() {
function g() {}
if (!("x" in g)) g.x = 12;
g.x += 10;
return g.x;
}
f();
f();
无论从那方面看,所有人都一致认可,上述的对g的functionBody的用法是equated的,因此可以成为joined function,结果就是第一次返回22,而第二次返回22(不join)或32(join)居然都是符合规范的。
对此,Brendan Eich(js之父,规范制定者之一)回复P T Withington(open laszlo的js引擎的开发者)说:
On Jul 31, 2007, at 5:41 AM, P T Withington wrote:
> Indeed. I was suggesting that the spec was broken; that it meant to
> prescribe an optimization to avoid unnecessary closures, but that it
> got it wrong (perhaps because it overlooked the mutability of the
> function object itself?). Surely backwards compatibility should not
> trump correctness? You don't want to have to force users to contrive
> to create a closure just to be able to add properties to a function?
No, none of that (breaking backward compatibility, requiring closures
for mutability) was desired.
I wasn't around for Edition 3 except for one or two meetings (pitched
sharp variables and uneval/toSource), but I talked to Waldemar about
this at some point. The goal was to allow an optimization that would
be implementation dependent. I believe mutability was forgotten. So
we should just remove all this joined function language.
我发了邮件到es4-discuss邮件列表上(讨论ecmascript4的官方列表)。
有了一些讨论,我这里不一一复述。仅说一下大概。
经过一些讨论,大家都认为joined function是有问题的,主要的问题是可能导致语义不一致的情况出现。有人写了一个比我的例子更有力的例子:
function f() {
function g() {}
if (!("x" in g)) g.x = 12;
g.x += 10;
return g.x;
}
f();
f();
无论从那方面看,所有人都一致认可,上述的对g的functionBody的用法是equated的,因此可以成为joined function,结果就是第一次返回22,而第二次返回22(不join)或32(join)居然都是符合规范的。
对此,Brendan Eich(js之父,规范制定者之一)回复P T Withington(open laszlo的js引擎的开发者)说:
On Jul 31, 2007, at 5:41 AM, P T Withington wrote:
> Indeed. I was suggesting that the spec was broken; that it meant to
> prescribe an optimization to avoid unnecessary closures, but that it
> got it wrong (perhaps because it overlooked the mutability of the
> function object itself?). Surely backwards compatibility should not
> trump correctness? You don't want to have to force users to contrive
> to create a closure just to be able to add properties to a function?
No, none of that (breaking backward compatibility, requiring closures
for mutability) was desired.
I wasn't around for Edition 3 except for one or two meetings (pitched
sharp variables and uneval/toSource), but I talked to Waldemar about
this at some point. The goal was to allow an optimization that would
be implementation dependent. I believe mutability was forgotten. So
we should just remove all this joined function language.
2 楼
fixopen
2007-08-14
我听说过ECMAScript导致了大量的微妙的错误。而ECMA却没有试图修正(至少表面上看起来是这样),而是不断的引入新的语言特性【也就因而引入更多的不一致和不自洽】,这事实上导致了js的不可移植。
1 楼
Lich_Ray
2007-07-21
飘过~~
发表评论
-
论ES6模块系统的静态解析
2013-03-14 04:56 15876本文是Dave Herman的《Stati ... -
如何创建一个JavaScript裸对象
2012-08-27 02:11 8050所谓裸对象,即 naked object ,是指没有原型(sp ... -
JavaScript语句后应该加分号么?
2012-06-19 03:10 14380这是一个老生常谈的问 ... -
shim是应该抛异常还是应该fail silently?
2011-08-11 17:26 5581玉伯发布了es5-safe模块 ... -
7月30日的广州演讲视频和Slides
2011-08-01 23:38 31757月30日在W3CTech广州站活动上的演讲,题目是:ECMA ... -
如何判断一个函数的意图是被用作构造器,也就是可视为“类”
2011-07-21 13:55 2948前提是不要求做什么特殊标记。只是最大可能的猜测函数的作用大概是 ... -
关于国内前端和JS技术发展的乱想
2011-07-19 18:53 33267玉伯在我的一条微博后面写了一些(和主题不是很相关但)非常值得思 ... -
Module与Trait的比较
2011-08-12 12:50 4004最近我多次提及module和trait。 粗看,我们可以发现 ... -
如何将let结构(block scope)转换到当前的JavaScript代码
2011-07-12 17:24 3009本文是对如何将let结构转换到ES3代码的补充。 首先,原文 ... -
JavaScript的未来方向之观察
2011-07-12 02:53 8373最近每次去杭州,都有 ... -
我为什么力挺NodeJS
2011-07-04 00:27 0之前在参加CNodeJS社区在 ... -
JS之父再谈JS历史(续完)
2010-12-31 04:20 3439又到年底,我觉得是时候还债了。自开blog来,我出了不少“太监 ... -
我为什么是DC黑续,兼答Tin
2010-04-27 14:29 0我同意安全是一个重要问题。我不同意的是把所谓安全放到凌驾于其他 ... -
我为什么是DC黑─Why I disagree with Douglas Crockford
2010-04-26 17:51 11016参加完了QCon北京大会, ... -
写对正则:一行代码,速度差50倍
2009-05-12 03:43 60132009-05-11 A lesson of ... -
JavaScript的EOS(分号)问题
2009-05-08 16:24 5779在http://bbs.51js.com/viewthre ... -
JavaScript五大关键字
2009-05-06 17:53 4768近期做语法高亮项目的副产品,是统计了一下几个主流JS工具包中各 ... -
curry和partial的差别
2009-03-28 00:15 371451js上asfman翻译了http://ejohn.org/ ... -
Eval is Evil , With evil too
2009-03-27 18:39 0with的问题: 2009-3-27 17:12:40 ... -
IE全局变量的Dissociative Identity Disorder(人格分裂症)
2009-03-16 02:47 14737最近,小麦提出了一个疑惑: 小麦 写道最后介绍一个我也搞不明白 ...
相关推荐
ECMAScript 2018规范。 主要包含内容: 异步迭代器:原生支持在 JavaScript 中对异步获取的数据做迭代。 Object Rest/Spread Properties Promise.prototype.finally Template Literal(模板字面量):取消 ...
ECMAScript 2020,也被称为ES2020或ECMAScript 11,是ECMAScript规范的最新版本,旨在定义JavaScript编程语言的标准。ECMAScript是由Ecma国际标准化组织制定的一个标准,它对JavaScript进行规范化,确保在不同平台和...
ECMAScript 语言规范是定义 JavaScript 语言标准的官方文档,由 ECMA 国际组织制定。JavaScript,尤其是 JScript,是微软对这个规范的一种实现,主要用于网页和服务器端脚本。虽然 JScript 主要与 ECMAScript 第三版...
资源名称:ECMAscript2018规范内容简介:ECMAscript 2018(第九版 JS)已于 6 月底正式发布,带来了许多新特性。ECMAscript 2018 于今年2月出炉草案,TC39 技术委员会每两个月开会一次,讨论当前...
11. **BOM与DOM**:虽然不是ECMAScript规范的一部分,但在浏览器环境中,ES3通常与浏览器对象模型(BOM)和文档对象模型(DOM)一起使用,实现页面交互和元素操作。 ECMAScript 3的影响力深远,它的很多特性在后续...
ECMAScript规范-第三版_中文版.pdf
**JavaScript与ECMAScript规范详解** JavaScript,一种广泛应用于网络开发的编程语言,其核心语法标准是由ECMA国际制定的,名为ECMAScript(ES)。最新版本的ECMAScript规范不断引入新的特性和功能,以适应不断变化...
ECMAScript2021中文最新,ECMAScript2021中文文档,第1-6章,持续更新,喜欢请star。git地址https://github.com/fangniyima/ECMAScript-notes
- **随后的几年**,JavaScript继续演进,从1.3到1.8,逐步增强其功能并逐渐与ECMAScript规范保持一致,尤其是在Firefox 1.0中搭载的JavaScript 1.5,这是一个里程碑式的版本,完全遵循ECMA-262规范第三版。...
**一致性**:ECMAScript 5.1 规范强调了一致性的重要性,确保不同的实现之间能够尽可能地保持一致。这包括但不限于语法的一致性、语义的一致性以及类型系统的一致性等。 #### 二、概述与术语定义 ECMAScript 是一...
标题中的“Babel preset能够让Node v6完全兼容最新ECMAScript规范”意味着,Babel预设(preset)是一个工具,它的主要任务是帮助JavaScript开发者将使用了最新ES规范的代码转换为可以在Node.js v6环境中运行的代码。...
ECMAScript6规范标准:let 和 const 命令、变量的解构赋值、字符串的扩展、数值的扩展、函数的扩展等。
ECMAScript的modules规范详解
ECMAScript规范摘要操作。 每个操作都可以按版本/年份和名称进行使用-例如, es-abstract/2020/Call提供ES2020中的Call操作, es-abstract/5/Type提供ES5中的Type操作。 es5 / es5 / es2015 / es2016 / es2017 / ...
ECMAScript 手册是关于ECMAScript语言的权威指南,该语言规范是JavaScript和JScript等编程语言的基础。ECMAScript由Brendan Eich在Netscape公司发明,并首次应用于Navigator 2.0浏览器,后来被所有Netscape和从...
ECMAScript,通常简称为ES,是JavaScript编程语言的标准,由欧洲计算机制造商协会(ECMA)制定并维护的ECMA-262规范定义。这个标准最初是基于Brendan Eich创建的JavaScript语言,目的是为了让脚本语言在不同平台上...
简单来说,ECMAScript是一种规范或标准,而JavaScript是一种具体的实现,即一种编程语言,它遵循ECMAScript标准。 1. **ECMAScript**: 是一种脚本语言的标准,由ECMA国际组织制定。它定义了脚本语言的核心特性,...
js 学习必备。 ECMAScript5.1中文版