49 条回复 2024-01-16 09:35:09 +08:00
 | 1 phoenixlzx 2015-07-27 11:17:49 +08:00 via Android 卷写 js还没用过 class 来着 |
 | 2 FrankFang128 2015-07-27 11:19:29 +08:00 我实名拒绝在 Javascript 里使用 class |
 | 3 yakczh 2015-07-27 11:32:11 +08:00 原型挺好的,需要什么功能就动态加上就行了, 如果按java那样搞,需要动态功能了,那得在内存中修改字节码 |
 | 4 tushiner 2015-07-27 11:43:18 +08:00  1 妄图给js强加传统oo特性的都是不懂装懂之人 |
 | 6 magicyu1986 2015-07-27 11:45:15 +08:00 class属于有的没的东西，有了更好，没了也将就（好吧，每个人都写过一个拷贝式继承函数对吧）。 给一个正儿八经的int跟byte才是王道。看着用64位浮点模拟byte好可怜。 |
 | 7 Yuianrong 2015-07-27 11:49:27 +08:00 继承结构复杂的情况下用class style很好，很能解决问题。 说这种话的人我觉得是没经过大脑，去看看browser自己的实现，随便找一个： HTMLDivElement -> HTMLElement -> Element -> Node -> EventTarget -> Object 这哪里是什么“清晰，整洁，也更符合语言”的原型方式啦…… 项目复杂的话，用同样方式抽象不是非常合理的吗…… |
 | 9 matsuijurina 2015-07-27 11:51:44 +08:00 via iPad 反正我用coffeescript |
| 10 tushiner 2015-07-27 11:53:37 +08:00 @YuJianrong 楼主的意思是，不要将传统面向对象语言的class与js的prototype混为一谈，没有说不使用继承、封装等思想。 |
 | 11 otakustay 2015-07-27 11:56:13 +08:00 1 这作者简直在扯谈 《停止将Javascript类型化，不要使用class》 《停止将Javascript函数化，不要使用function作为第一级对象》 然后Javascript就消失了呗 而且论点站不住脚，因为一个东西可能被人误解，所以我们不要用它，这样的话社会永远没有进步 |
| 12 YuJianrong 2015-07-27 12:02:37 +08:00 @tushiner 仔细看看文章去： 我很清楚经典继承方式的吸引力。甚至道格拉斯Crockford， Javascript Good Parts （原声PPT） 作者 都实现了一个经典的伪继承 ， 开明的Javascript的创造者布Brendan Eich似乎喜欢很ES6中的class。对于许多程序员来说，这是在他们使用Javascript之前很熟悉和舒适的编程方式。然而，Javascript并不是一个经典的语言，语法糖和ES6的新class关键字只是在自欺欺人。 ... ...如果你想了解 class 这样的关键字为什么那么可怕，为什么原型继承比经典的好.... 这还不是明说了不要搞继承要用原型吗…… |
 | 13 learnshare 2015-07-27 12:05:29 +08:00 1 人生苦短，我用 TypeScript |
 | 14 tabris17 2015-07-27 12:06:05 +08:00 我觉得原型的最大弊端就是容易写出糟糕的代码，而且这种代码根本无法阅读和调试 |
| 15 tushiner 2015-07-27 12:07:23 +08:00 @YuJianrong ”使用原型“就是js版本的”继承“，继承是一种思想，而不是语法，与关键字、表达式结构无关。 |
 | 17 ixiaohei 2015-07-27 12:18:55 +08:00 读不懂这文章讲的啥 |
 | 18 Jex 2015-07-27 12:29:34 +08:00 2 前几天刚说过某些 Javascript 程序员压根不懂 OOP 就在那瞎扯有的没的： http://www.zhihu.com/question/24076626/answer/55284360 怎么又来瞎扯个不停呢。 《请停止向 Javascript 中添加 yield，用 callback 即可》 《请停止向 Javascript 中添加 let，用闭包即可》 《请停止向汇编语言中添加 call 指令，用 push jump即可》 这就有点像CISC跟RISC之争一样，事实上只需要一个翻译器运行时将复杂指令再转换成精简指令就行。之所以要有程序语言就是为的抽象啊。 我在话题下面说过了，https://v2ex.com/t/201281 ，现实会来打他们的脸。 原来我曾经看过的GC测试是在你博客上看到的 @otakustay http://otakustay.com/about-closure-and-gc/ |
 | 20 datou552211 2015-07-27 12:49:06 +08:00 via iPhone @tabris17 只能说实现特定功能的语法糖太多了不好 |
| 21 Jex 2015-07-27 12:57:55 +08:00 @otakustay 感谢你的详细测试，我相信其中「多个嵌套函数」一例从原理上来讲是一个Bug，将来会被解决。另外有一个补充，Direct Eval Call 第二个要求是 GetValue的值必须是标准 built-in eval function，但这点JS解释器是无法静态推断的，所以JS解释器GC上认可的只有第一个要求，即名字是 eval的 Call Expression就行了。所以在非Strict ES5下，并不是「非直接eval」（也就是「间接 eval」，Global scope的eval）就一定可以被GC。 |
| 22 otakustay 2015-07-27 13:04:22 +08:00 @Jex 我当时认为“多函数嵌套”下如此粗暴的GC机制是为了整体性能上的衡量，也出于那个时代Javascript为基础的大型应用/游戏并不流行的前提，现在是怎么样不大清楚了，好久没再测一下了 关于eval那段是没错，或者我这么理解：非严格模式下浏览器基于静态lexical分析对直接eval的判断不特别准，而GC机制并不与eval实际执行时的状态（直接/间接）关联，而是和静态分析关联 |
 | 23 21paradox 2015-07-27 13:56:16 +08:00 不知道为啥这么多人讨厌coffeescript |
| 24 Jex 2015-07-27 14:02:17 +08:00 @otakustay 是的，因为可能同样的代码`eval(code)`这次调用是Direct下次又变成Indirect了，所以原理上解释器无法作普适的优化。 |
 | 25 fds 2015-07-27 14:11:10 +08:00 看到文章中说 “CoffeeScript就不一样，它是完全不同的。如果没有学过该语言，它会很难读懂” 就觉得没有继续看下去的必要了。coffee明明只是个语法糖，跟js是直译的。作者这点儿功力就不要阻挡潮流了。 |
| 26 YuJianrong 2015-07-27 14:20:31 +08:00 @tushiner 好吧确实原型继承也是继承。不过JS版的class实现说到底也是建立prototype chain的helper而已，实在感觉不到黑点…… |
 | 27 MyLady 2015-07-27 15:00:15 +08:00 爱用用,不爱用就不用又没人强迫你... 如果没人觉得OOP好那Mootools早死了吧 |
 | 29 secondwtq 2015-07-27 15:21:40 +08:00 @learnshare 握爪。 我认为 Coffee 的目的是将 JS Ruby 化，TypeScript 的目的是将 JS C# 化，两者都没有也不可能把这个事情做彻底。 我最近随便看了一个开发 HTML5 游戏的库 Phaser。该库的作者在 13 年 8 月发过一个贴子征集意见： http://www.html5gamedevs.com/topic/1218-would-any-of-you-care-if-i-dropped-typescript-support-from-phaser/ 在 15 年 4 月又发过一个贴子： http://www.html5gamedevs.com/topic/13599-reconsidering-building-phaser-3-in-typescript/ 两个贴子的回复中撕比成分较多，我都没有全部看完，但是可以根据记忆大概说一下内容。 Phaser 貌似原来是使用 TypeScript 构建的，然而随着工程不断展开，遇到了问题。那时候 TS 不很成熟，尤其是工具链，经常出现崩溃之类问题，作者忍无可忍，用 Javascript 重写了整个库。但是并没有完全放弃 TS，官方依然维护着一套 .d.ts 文件。但是"things don't sit still for long in the web world"，现在 TypeScript 越来越成熟，作者在考虑换回去。实际上使用 JS 和使用 TS 都有各自的利弊，这个跑题太远按下不表。但之所以不使用 TS 是因为一些其他的实际问题，比如工具、编译环节、TS 自身的小众、community 贡献的限制甚至 M$ 之前的一贯德行等，确实有许多人承认，TypeScript 是构建游戏的优秀工具。作者说过他虽然不使用 TS 写库了，但是依然会用 TS 写自己的游戏。 TS 还有一个好处，就是向下兼容 JS，并且对 ES6 有支持，这是 CoffeeScript 貌似难以做到的。 |
| 30 learnshare 2015-07-27 15:56:08 +08:00 面向对象、继承 都是编写复杂应用的重要条件，原型、class 的继承方式是两种不同的实现方式而已，没什么优劣。在 ES6 获得广泛支持之前，伪 ES6 的工具还是要编译成 ES5 的原型继承来用。 能烧火的就是好柴，不管是树墩还是牙签。 |
 | 31 bramblex 2015-07-27 16:56:59 +08:00 |
| 32 bramblex 2015-07-27 16:59:36 +08:00 要怪就怪自己没本事折腾，别说Javascript可以折腾出来类继承了，VimScript这种蛋疼货一样可以 |
 | 34 anubiskong 2015-07-27 19:44:20 +08:00 "大部分语言发展到一定程度就开始模仿lisp" 忘记谁说的了, 我认为基本是对的, JS应该走自己的路, 学java那套就和PHP当初学java一样最后会变成屎 |
 | 35 jiongxiaobu 2015-07-27 21:11:56 +08:00 |
| 36 YuJianrong 2015-07-27 22:43:36 +08:00 1 |
 | 37 hitsmaxft 2015-07-27 22:59:30 +08:00 via iPhone 原型链什么的黑魔法不适合连类型继承怎么都不清楚用不好的程序员，大概就是这么回事。 |
 | 38 onceyoung 2015-07-27 23:06:30 +08:00 @FrankFang128 现在我们的项目里就模拟了一套class的机制，相当的蛋疼，看着不伦不类 |
 | 39 zonghua 2015-07-28 02:22:03 +08:00 via iPhone 递归拷贝实现继承吗？ |
 | 40 guotie 2015-07-28 08:55:29 +08:00 es6怎么办 |
| 41 anubiskong 2015-07-28 09:29:00 +08:00 @YuJianrong 谁都没说lisp会"站上主流", 但是它的概念却统治了编程世界, 这是大势所趋, 你身在其中却没有察觉到而已 |
 | 42 whimsySun 2015-07-28 09:59:41 +08:00 楼主大概想自己搞了半天才弄明白原型链继承，来了一个java/c#/c++ 程序员，一下就能用上class继承了，心里十分不爽。class作为ES6引入的语法糖，基本上和coffeescript里的class相同，js需要发展，必然会引入其他成熟的语法，当然你也可以选择不用。 |
| 43 YuJianrong 2015-07-28 10:45:08 +08:00 @anubiskong 来点干货好不好……lisp什么概念要统治编程了？ |
 | 44 qianleilei 2015-07-28 11:01:37 +08:00 呵呵... |
| 46 anubiskong 2015-07-28 18:12:32 +08:00 @YuJianrong 干货在我第一个评论就给你了, 你还想让我怎么给你讲 |
| 47 YuJianrong 2015-07-28 18:37:53 +08:00 @anubiskong anubiskong 22 小时 51 分钟前 "大部分语言发展到一定程度就开始模仿lisp" 忘记谁说的了, 我认为基本是对的, JS应该走自己的路, 学java那套就和PHP当初学java一样最后会变成屎 这也能叫干货……敢情您还定义了干货呢…… |
 | 48 invite 2015-07-29 08:38:21 +08:00 过段时间应该会有： “请停止使用Javascript” 的文章出来了。 |
 | 49 zangzang 2024-01-16 09:35:09 +08:00 @learnshare #13 现在主流了 预言家 |
Select Language