【cocos2d-x从c++到js】08：JS脚本语言的优势与一些问题

优势：

1.不需声明，甚至匿名方式原地定义。编码量少。

这一条在C++中尤其明显，以绑定一个回调为例，需要声明，定义，调用绑定，三处代码。虽然C++11中支持lambda表达式，对于回调的写法有很大改进。但是其他地方依然蛋疼。

2.弱类型语言，一般情况下，不需关心实际类型。Debug时除外。

在使用C++这种强类型语言的开发中，尤其是写功能代码时，类型检查远不如想象中那么有用，很多时候反而是问题根源，编译不通过时，很大一部分时间是在对变量类型，由此还衍生出一些特殊技术手段，比如适配器模式等等。

使用JS这种弱类型语言，只要接口名称能对上，那么在对象的函数被调用时就认为是正确的。简单说，只要长得像某一类型就行了，不需要必须是某一类型。

C++11中auto关键字也可以提升编码速度（和JS的var很类似，可以随时无脑输出），不过看了一下引擎附带的几个例子代码，好像有滥用auto的趋势。

3.脚本语言动态扩展能力强，可以不必构造很多临时类型和消息类型。

比如，在大型游戏中，全局使用消息机制时，C++可能用结构体，自定义类，或者我们以前直接丢JSON对象过去。在JS里面就很简单了，直接扔JSON对象吧。

在运行时可以动态给一个对象添加函数和属性，而不需要重新构造新类和初始化。JSON源自JS，JSON是天然的消息对象，非常合适。当然JSON有自身的缺点，访问父节点和兄弟节点不太方便。并且JSON的结构和二维表没法完全兼容，这是一直让策划和工具程序员头痛的一个问题。

4.语法灵活，可以支持各种编码方式。随机应变。

业界普遍认为面向对象在图像编程是最好的。但对于事件处理逻辑处理AI处理来说，面向对象则是罗嗦的要死。比如，我实在对观察者模式提不起兴趣，Qt中的信号槽机制优雅的多。又比如我曾经做了一个A*算法代码，想改成好用的面向对象方式，发现很痛苦。

JS很灵活，适合什么样的编码方式，就用什么样的方式。

5.在语言级别天生集成了两种最有用的数据结构，向量和映射表。

记得在KJava时代，MIDP的里面只有很少的数据结构，里面就有向量和哈西表。这两种是最为常用的。JS在语言层面提供了支持，编码极其方便。

6.脚本语言无需编译，大量节约了开发时间。

如果你在Mac上，并且开了虚拟机然后编译VS的话，应该有那个恐怖的按小时计算的编译时间长度经验。Clang虽然速度比VC快很多，但是每次如果clean一下然后编译几十上百个文件也需要若干分钟。

一些问题：

1.太灵活，更容易出烂代码。

2.调试问题与IDE问题。

目前在cocos2d-x领域，还缺乏好用的支持JS的IDE。现在目前暂时还是用cocos2d-html5版本做调试（两者的接口已经高度一致化），未来会有基于c++的IDE做的JS调试插件（比如在Eclipse上面的）。

3.善变的this

this关键字绝对是JS里面的变形金刚。根据不同的上下文，经常会变成其他东西。

这个经常会和回调函数问题纠缠不清，如果再加上闭包，三合一，够你喝一壶的。

4.闭包

闭包很强大，无限制传参，抓取快照。

但是闭包本身的问题也不小，首先是阅读和理解上的困难，面向对象的程序员一上来很难理解这东西，从他们的角度看闭包的代码也很丑。

还有就是效率问题，同事测了一下SpiderMonkey中的闭包在生成大对象时效率不太高。

目前在cocos2d-x前端开发中，为了防止出现问题，对于缺乏经验的程序员，尽量不要使用闭包代码。

我个人在回合制战报，生成动画里是用了一些闭包的，不过那是一次性代码。

5.变量生命周期不明确

变量生命周期问题，因为不需要声明，很多时候也没有特别明显的初始化，并不能通过阅读代码明确知道，一个变量的生存周期，这是所有脚本语言和GC语言的特性，有些时候对调试会形成麻烦。

6.原型继承

难以理解的原型继承。熟悉面向对象的人一般都对这个东西莫名其妙。

从静态语言过度到动态脚本语言，一般程序员会疑惑在几个地方，this，闭包，原型继承，以及如何灵活地使用脚本语言的动态性进行编码，我观察了一下，很多人写JS像静态语言，还是c++风格或者Java风格。