[译]ECMAScript常见问题解答

原文:http://tc39wiki.calculist.org/about/faq

什么是"一个JavaScript"的原则?

"一个JavaScript",或者简写为1JS,意思是不能分裂JavaScript,每个版本的规范都必须要和和前一版规范保持向后兼容.我们可以通过添加新的API和新的语法来改进这门语言,但我们不能改变那些已有的特性.出自One JavaScript提案

译者注:从这一点上看,JavaScript是门很有特色的编程语言.为什么说有特色?Perl6和Perl5,Python3和Python2,Ruby1.9和Ruby1.8,为什么它们可以不向后兼容?根本原因就是:它们都不是web前台语言,用什么解释器是由编程者自己决定的,即便Perl6变成一门新的语言,有了两个Perl,也ok.但是JavaScript就不行了,你无法控制用户使用什么浏览器.所以作为唯一的一种使用在浏览器上的编程语言,JavaScript的规范必须尽可能的向后兼容.

为什么我们不删除或修正那些已有的不好的特性?

如果我们这么做了,某些已经存在的网页将无法正常运行.没有一家浏览器厂商会愿意做这些事,因为普通用户会认为这是bug,从而转向其他的浏览器.

唯一可以作出这种不兼容的改变的时机就是在因特网上没有网页依赖这个特性的时候.除了试验,我们没有任何手段能判断出到底有没有网页依赖这个特性.浏览器制造商可以尝试冒一次险,在自己浏览器的alpha或beta版本中进行这种不兼容的改变,看看是否会有用户提出与该特性有关的bug.

译者注:Google曾经在v8中实现了"harmony:typeof_null",也就是让typeof null === "null"这个特性,这正是很多开发人员向往已久的表现.不过经过chrome19的实践证明,这么做不行,很多网站的类型检查代码都被破坏了,随后该提案也就被拒绝了.chrome也改回了原来的实现.不过就算现在,如果在node中使用了--harmony_typeof选项,也可以开启typeof null === "null"的特性.

还有个例子,是关于parseInt()转换8进制数字形式的字符串的问题.是我在"JavaScript高级程序设计 第三版" 3.4小节看到的.

书上说,parseInt("070")在ES5中会返回0,但实际上,所有的浏览器都没有按照这个标准实现.为什么?同样的原因.很多已有的代码使用到了parseInt的这个特性,没法按照标准执行.我在SpiderMonkey的源代码中找到了下面的注释.

    /* 15.1.2.2 step 9. */
    int radix = maybeRadix;
    if (radix == 0) {
        if (end - s >= 2 && s[0] == '0' && (s[1] != 'x' && s[1] != 'X')) {
            /*
             * Non-standard: ES5 requires that parseInt interpret leading-zero
             * strings not starting with "0x" or "0X" as decimal (absent an
             * explicitly specified non-zero radix), but we continue to
             * interpret such strings as octal, as per ES3 and web practice.
             */
            radix = 8;
        } else {
            radix = 10;
        }
    }

我认为,如果是这种情况,作者应该按浏览器的表现来讲.如果讲"ES5中是这样的,ES3是那样的,浏览器没按照ES5来实现"等等这些.这样肯定会给不少人带来困扰.尤其是新手,不是记错,就是记混.还不如索性不提.

同时,如果你在看这本书的时候没有发现这个问题,那么你只是在"背书".

为什么我们不给语言的版本号做重大变更?

在web领域,可选版本号有着很不好的记录.VBScript, JavaScript 1.2, 以及 XHTML都是例子.

版本和模式也许听起来很吸引人,但是它们的默认值是不对的:在未指定版本的情况下(比如,在一个script标签或者一个内联属性中),总会使用旧版本的语法.想要使用新版本的功能,必须指定版本号.而且在HTML标签的内嵌属性中根本不能指定语言的版本号.更糟糕的是,添加模式和版本号给应用程序的测试工作和平台特性可用性的跟踪工作增加了一个维度的难度.

因为这些原因,可选版本号很难被采纳.这同时也给了平台提供商一个很大的实现和测试上的负担,成倍的增加了他们的子平台,所以浏览器制造商通常返对新的模式.

译者注:这段基本不知道在讲什么!!应该是关于<script type="application/javascript;version=1.8"> //code</script>中的1.8这种版本选项的.

为什么我们不弃用一些特性?

在web开发领域中,将某个特性标记为"废弃特性"或者"不推荐"等字样并没有什么实际的作用.因为我们并不能删除这些不好的特性,开发者们也不会很主动的去停止使用这些特性(仅仅因为有些人不喜欢它?).

译者注:事实上,某些目前不推荐的特性,在未来甚至可能成为标准,比如__proto__.这就是所谓的"逆袭"吗?

如何在旧的浏览器中使用新特性?

新的语法从开始实现到足够多的用户使用量需要一段时间,不过,从历史上看来,在JavaScript中添加新的语法一直是比较成功的.举个例子,就是try/catch,该语法是在ES3(1999年)中引入的,花了很多年时间才实现广泛的应用,不过现在它已经成为了JavaScript中不可或缺的一部分.

在旧的浏览器中使用的新的语法的一种方式是,使用一个称之为"transpiler"的东西,把包含新特性的代码编译成旧版本的JavaScript.Google的Traceur compiler就是一个针对ES6的试验项目.

译者注:Github上有不少的ES shim项目.更新比较频繁的有这两个ES5 shim和ES6 shim.

JavaScript的下个版本什么时候可用?

ECMAScript 6规范计划在2013年正式发布,不过浏览器们已经开始逐步实现一些特性了.

有一些网站比如Can I Use和HTML5 Please记录了web相关的特性在浏览器上的支持情况.希望这些网站或者其他类似的网站可以把ES6的特性添加进去.

译者注:,推荐kangax总结的ES6兼容性表格,http://kangax.github.com/es5-compat-table/es6/

我们会给严格模式添加新的限制吗?

不会.严格模式仅仅是用来修复ES3中的一些问题的一次性事件(one-time event).未来,ES6中的模块默认就是严格模式,但是本着一个JavaScript的精神,我们会避免添加更多的特性修复.

译者注:建议读者在写代码的时候加上"use strict",像perl程序员一样,他们几乎没有不加use strict的.

为什么不使用字节码虚拟机?

基于字节码的语言通常都需要一个验证器,这可能会影响启动速度,还会导致代码的臃肿,导致下载量增大,增加网络延迟.现在有很多编译器可以把其他源代码编译生成JavaScript代码,TC39的一个明确目标是尽可能有效的帮助这些代码生成器以及程序员们.

译者注:字节码虚拟机相关链接http://www.dartlang.org/articles/why-not-bytecode/

有类了? 难道JavaScript真的要变成Java了?

不可能! ES6中的"类"仅仅是JavaScript中一直存在的"构造函数加原型"模式的一种新的语法形式.这种"类"完全是动态的.

译者注:也就是说,如果你不喜欢,可以不用"类",用以前的"prototype".

如何避免"完全由委员会设计的规范"?

TC39按照Harmony process来执行规范的设计工作.首先由一组小团队独立完成某个特性的草稿设计,然后将草稿提交给委员会,与委员会其他的成员进行讨论.同时这个小组就作为了该特性设计的"领军者".如果委员会同意了该设计草稿,那么这个设计草稿就会被提升成为官方提案,提案的"冠军"继续领导该特性的设计工作.

译者注:TC39中的很多成员都活跃在twitter和stackoverflow上,目前有21位成员,你应该在twitter上关注他们,只认识"道格拉斯"可不行.

这么多的设计草稿是不是意味着JS会变的臃肿?

绝对不是的.大多数的设计草稿都不会成为最终的官方提案.我们只会从许许多多的设计草稿中挑出最好的一些.TC39会尽早的把设计草稿公布于众,来尽可能的鼓励更多的人提交反馈.

译者注:虽说没有变的臃肿,但绝对可以说是庞大.ES6相对于ES5的学习曲线绝对比ES5相对于ES3的陡峭许多,同时搭配上"广义的HTML5"里的新东西,要学的知识太多了,应该尽早做准备.

我怎么能提交一个建议?

发邮件到es-discuss!

在es-discuss上发帖我比较紧张,有什么建议吗?

只要让你的文字保持简洁并且有建设性即可.我们很欢迎大家做出建议和反馈.

如果你还不是很明确的知道自己所理想的解决方案是什么,不要着急:只需要描述出你所遇到的问题就行.开发人员提供的关于常见问题的反馈也可以是很有价值的.

另外: 请去掉引用的文字,只保留自己发表的文字(Gmail用户注意了:引用文字默认是隐藏的,但还是会发送出去,你要让它显示出来,并删除掉).

译者注:虽然以我的能力还远远不够在上面发言,不过我经常会上去看看.

怎么拼(读)JavaScript? ECMAScript? Ecma?

JavaScript, ECMAScript, Ecma.

译者注:这条应该是作者Dave Herman在搞笑.Dave Herman的新书Effective JavaScript就要出版了.我很期待.

posted @ 2012-11-06 10:30  紫云飞  阅读(1412)  评论(2)  编辑  收藏  举报