目前问题确实不少，无形中增加了我们开发的时间成本，希望独立出来的团队能够把quick做的更好:870:
— Begin quote from ____
引用第20楼zhuangzaiku于2014-11-28 16:42发表的 :
目前问题确实不少，无形中增加了我们开发的时间成本，希望独立出来的团队能够把quick做的更好:870: http://www.cocoachina.com/bbs/job.php?action=topost&tid=272354&pid=1185288
— End quote
一定的！
都是1群传说级的人物啊
必须顶~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
来顶廖大
感谢廖大团队对quick的每一步推进！
感谢开源！
cocos2d-x lua感觉都没什么存在的必要，触控这么做算是做对了，下一步直接融合两者形成最终的quick才是极好的！
期待~
廖大有几个问题请教下哈
- 现在cocos 1.0 preview还没有集成lua，以后集成后是不是直接就包含quick了？(就是quick==cocos lua)
- 现在一直没找到100%顺手的lua编辑器。以前一直用xcode感觉这是我用到的最好的代码编辑器/IDE了，VS之流简直没法比呀… 可是用lua还是没找到真正顺手的编辑器，Coco Code IDE感觉就是一款残疾产品…首先基于Eclipse，那就是各种慢！卡！slow！同样一个代码提示有时能弹出，有时弹不出，有时过了好几秒才弹出… 有些永远也弹不出… 用时间长了产品没做完 自己就被气死了！sublime是款非常好的工具，但毕竟不是cocos官方出的，与cocos lua集成度非常有限。希望廖大能给指出一条明路。
赞一个！努力加油，共同进步
这个一定要支持
期待尽快发布
意思是，quick被边缘化了，主力cocos2d-lua
太好了！我一直都不知道我改进的一些cocos2d-lua的部分（比如LuaStack这样
）应该提交到哪儿去，这下子好了（虽然还是不知道该提交到哪儿去= =）
另外，我想说一下关于tolua的绑定的问题，有机会我想另外在issue里面单独开
一个详细讲这个，但是现在不知道cocos2d-lua的仓库到底在哪儿啊= =所以现在
这里先说说。
我是10年的时候在自己的项目里面用tolua++的，当时用的是一个带插件的版本
，插件支持了虚函数调用。后期的时候在开发中随着对lua的了解，一直想把
tolua给换掉。
主要的一些动机是这样的：
- tolua生成的代码太难看了
- tolua直接生成函数调用来注册函数，而不是通过标准Lua的luaL_Reg注册表机制
- tolua的文件分离，接口不好查询
- tolua的lua方面的接口功能过于简单。
- tolua不支持enum绑定
等等的一些原因，反正让我产生了重新发明轮子的想法。但是一个C++ -> binding
的生成器本身让我反复犹豫，因为可以采用的技术太多，而C++本身的语法又是
比较暧昧不清的。在几年的时间里面，我分别考虑了几种不同的绑定方法：
- 通过一个接口文件导出（tolua的方案）
- 通过一个编译器产生的xml文件导出（现在的cocos的方案）
- 通过手写一个合法的lua文件（但格式是DSL形式的）来导出（LuaNativeObject方案）
这么多不同的生成方法，各个都有各自的问题，其实主要的问题在于，C++的接
口语义是不清晰的，而定义清晰语义又需要对C++本身理解透彻。因此我暂时放
下了这部分的开发，并开始开发一个最适合被绑定生成器使用的运行时（
runtime），这个运行时就是lbind项目目前的成果：
http://github.com/starwing/lbind
lbind项目目前真正完全经过了数个项目实践的是它的runtime部分。lbind.h和
lbind.c，它们共同实现了一套解离的Lua辅助库，主要的特性是：
- 清晰、现代的Lua C库代码风格，方便修改、增强。
- 一套独立的错误处理机制，完善的保护运行机制。
- 下面的各项功能都是可选的，如果不选择，就不会影响效率
- 利用lbind_Reg注册表的多模块注册机制。
- 一套元表增强机制，通用的__index，__newindex函数。
- 轻量级的userdata支持（带uservalue的lightuserdata）
- 一套完整的类型系统，支持多重继承的绑定。
- 通过void*而不是类型名的查找，按照lua-l的测试，能提高30%左右的性
能。
- 注册udbox，能通过对象void*找到对象本身（关键是，这个特性是可选的
，因此对于一些非常频繁使用又没有这种需求的对象，能通过禁用这个特
性提高性能）
- 一套十分完善和清晰的对象操作接口，而且在Lua层面也可以得到几乎一
样的功能（require "lbind"接口）
- 可选的对枚举的绑定，支持字符串枚举值解析，支持枚举bitmask解析。
这套接口被特意设定为，即使是手写绑定也会写起来很舒服的接口。我已经利用
这套runtime实现了多个手写绑定，充分验证了它的可行性。
我希望，在这样的一个时候，我们可以考虑替换掉binding-generator，让其生
成绑定lbind的代码，彻底扔掉lua5.0风格的tolua运行时，而改进成lua5.2风格
的lbind运行时。
在这个过程中，lbind本身可以积攒一套实际可用的绑定生成器代码，而cocos也
可以获得一套稳定、清晰、小巧的lua绑定代码。我想这是对两个项目都很好的
一件事。我本人目前在上海工作，业余时间不是特别的多，但是也很高兴能够提
供我自己的业余时间，来做适配、bug解决、新特性等等方面的工作。
谢谢！
这个非常棒！必须支持
看了介绍觉得很眼熟，再一点仓库，发现果然是自己已经收藏过的了。之前在考察各种 luabinding 库的时候，已经初步筛选出来了一些项目，其中就有 lbind 
tolua++ 早在 2009 年就没有再更新了。tolua++ 本身存在不少问题，也不支持 Lua 5.2 新版，所以我们今年上半年就打算换掉 tolua++ 了。但因为 quick 团队以前很难向 cocos2d-lua 提交这么大的改动，所以做了一些测试后没有付诸行动。而现在这些障碍消除后，换掉 tolua++ 是必然的。
只是选择一个新的 luabinding 库，需要满足一些基本要求：
- 支持 Lua/LuaJIT
- 支持足够的 C++ 特性，例如重载、虚函数、多重继承等等
- 类型安全
- 高性能
从 lbind 的介绍看，应该是没有大问题的。
so, 我们一起把这个事情搞起来吧，double win !
31楼，这个非常棒！
廖大辛苦了…大力支持…~~~~
刚选择quick两个月，看到quick的活力和进步，感觉当时的选择是对的，quick加油！
廖大威武！！！
是否考虑加入WebView支持呀？
quick团队辛苦廖大辛苦顶一个~
很是期待，尤其是好用的文档工具。