トップページ > プログラム > 2015年07月26日 > OcTVoTNp

書き込み順位＆時間帯一覧

36 位/166 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000000000000000022



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
ECMAScript デス 4

書き込みレス一覧

ECMAScript デス 4
784 ：デフォルトの名無しさん[sage]：2015/07/26(日) 23:04:38.16 ID:OcTVoTNp
そんな事言い出したら構文レベルでない物は全て不要になると思う。
それこそDateやMathだって別にライブラリとして作れるんだし。
でもあって便利だからあるのは間違いじゃないと思う。

そしてジェネレーターなんかの新構文だってES6to5トランスレータがしてるように
switchなんかで再現するのもそう難しくないし、多くが糖衣構文で別に重いものでもないともいえる。
そもそも当然ES1の頃からチューリング完全なんだから、
後はどれだけ世の中の要求に合わせて便利にしていくかということしかないだろう。

そしてMapだけ[]を特別視するというのはメリット少ないし、筋が良くない。
１つ言うとmap[]で他と揃うと言うが、そうは思えないんだが仮にそこの面はそうだとしても、
他方でSymbolかMap.getSize(map)のような存在や手法を入れないといけないのは
今のmap.sizeと比べるとけして他と揃っているとも言えないし、不自然だ。

それらの特別なルールをいくつも入れて生まれると主張している自然性とメリットは、
同じく生まれざるを得ない不自然性とデメリットによって相殺されている。
総合的に見てmap.get、map.setという作りが簡単なAPIである方が良いと思う。

もしどうしても[]をどうにかしたいのなら、
Dartのように演算子オーバーロードとしてより汎用的な仕組みを入れた方がいい。
ECMAScript デス 4
785 ：デフォルトの名無しさん[sage]：2015/07/26(日) 23:21:50.83 ID:OcTVoTNp
あとクラスもどきをクラスにするというが、
具体的に今のES仕様上に一体どのようにすれば構築するのかできるのなら説明して欲しい。
というかESへのクラスベースの導入なんてもはや100％不可能なことと考えて欲しい。
そこら辺はあくまでプロトタイプベースを活かしてどう糖衣構文を入れていくかという話しか絶対にありえない。

いくらそこがそもそも気に食わないと言ってももはやどうしようもない。
JSは歳の割にかなり拡張性と将来性を残している言語だが、
もうそこの部分は良かれ悪かれどうこうしようがないことなので完全に受け入れた上で、アイディアを出して欲しい。

今Googleが提案しているような、ES内に別モード（実質別言語）を持ち込むというような話でならいくらでも可能だ。
逆に言うとそこを変えてしまうと、もはやESではないということだ。
他にも、この仕様こそがESであり、それが仮に悪いものであっても単純にそうでなくすとESでなくなるよねということは多くある。
皆はそうしたデリケートな観念を共有して、あくまでESをESのまま良くしていこうとしているわけだ。

そこにズカズカと、好きな仕様をどうにでも定められるだろうというようなスタンスで来られると困惑する。


※このページは、『２ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の２ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。