- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ51【php,py,pl,rb】©2ch.net
309 ：デフォルトの名無しさん[sage]：2015/08/09(日) 00:16:47.88 ID:3uPolmYz - >>304
> それはちょっと違うんじゃないか？
> それらはむしろ実行時以外でこそ、マシンではなく人にとって役立てるものだと自分は認識している
それは君の解釈がそうだというだけ。もちろんそういう人もいていい。
そしてこの解釈＝可読性だけなら、ES6で実現できる。
ただ、従来のクラスシステムは動的保護を持っていたため、オブジェクト指向を強制することが出来た。
つまり、提供しているインタフェース以外ではどうやってもアクセス出来なかったため、
private/publicについては、そう書いてある限りそうだと保証できた。
ところが今のJavaScriptでprivate/publicを提供したところで、
「私はこう書いたつもりですけど、間違っているかもしれません。
もちろん他の人が書き換えているかもしれません」
でしかなく、従来のクラスシステムの代替とはならない。というか、何の意味もない。
ただのコメントでしかない。だったらコメントを書いた方がマシだ。
これが分からないのはお前らJavaScripterが無知だからだ。
お前らは一度他言語を触ったほうがいい。
マンセーばかりしているからおかしな事になっている。
言語を作るような奴は、譲れないポリシーがあって、彼等から見て最高に美しいものを作ろうとしている。
それが気に入るかはともかくとして、とにかくそうなんだ。
だから『技術的に』生き残っている言語は、どれも一芸に秀でている。
JavaScriptは『政治的に』生き残っているだけだ。
> 実行時のことだけであれば君が言うようにそういう記述的なもので無くてもいろいろ何とか出来そうだ
これは出来ないと思うぞ。
ニーズは昔からあったはずだから、糖衣構文で対応できるのなら、既に誰かがやっているはず。
ていうかお前も何でそんなに馬鹿なのよ？
本当に揃いも揃ってJavaScripterは何でこうなの？
みんなが出来なかったことは出来ないこと/難しいってことが分からないの？一通りの知識もないくせに。
| - 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ51【php,py,pl,rb】©2ch.net
320 ：デフォルトの名無しさん[sage]：2015/08/09(日) 01:07:59.72 ID:3uPolmYz - >>312
> 可読性と実行時の保証ということであれば、実現可能で
> ES7でもプロポーサルが上がってて重要度は高い
これは多分ずっと上がってたんだと思うぞ。
ただ、動的保護あり/なしは本質的な変更だから、今までのESxを見ている限り、ねじ込むのは無理だ。
あと、動的保護自体はcallbackと相性が悪い。全部publicにしないと見えなくなる。
(隠すのならasync-awaitかpromiseかを使ってはめ込むことになるのだろうが、
これらについては俺自身が味見していないのでどこまで出来るものなのかは分からない。)
> あともう一つ要素を挙げるなら最適化による速度の問題か
これも勘違いで、みんな分かっててやっていることなんだ。
オブジェクト指向も、動的保護も、重くて遅いものだ。でも生産性のためにそのコストを払っている。
JavaはよくCと速度比較しているが、あれは全て寝言で、
動的保護が付いたオブジェクト指向で書いている限り、保護のないnativeCに勝てるはずはない。
だから速度競争が熾烈だったブラウザをJavaで書いている馬鹿は誰もいないだろ。C系でやるしかないんだ。
でも絶対に落ちてはいけない業務系はJavaが全盛だろ。（聞いただけだが）
安全第一ならCなんてあり得ないんだよ。遅いけど安全のためには仕方ない。そういう選択だ。
お前らJavaScripterが間違っているのは、全取りを目指していることだ。それは出来ないんだ。
短所を改善するのではなく、長所をさらに伸ばすべきなんだよ。
そして今のJavaScriptには『技術的な』長所がない。だから他言語が使える状況でわざわざ使う意味がない。
なおクラス関係なく「最適化だけ」の意味であった場合は、言語仕様と関係なく頑張ればいいだけだ。
最適化のための記述を導入するのは余計に話がややこしくなる。
ただ、TypedArrayとかはWebGL側からの要求だと思うから、必要だったのだとは思う。
しかしつまるところ、あれこれ詰め込みすぎだ。
そういうのは本来はフレームワークとして分離すべきだ。例えばC#の仕様と.NETのバージョンは別管理だ。
ESはそこら辺もごちゃ混ぜなのがよくない。
| - 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ51【php,py,pl,rb】©2ch.net
330 ：デフォルトの名無しさん[sage]：2015/08/09(日) 02:44:45.12 ID:3uPolmYz - >>323
ちなみに仕様と実装は分離した方がいい。
C++みたいに仕様がアレ過ぎて実装できないのはやや問題だが、
実装を考えた仕様にすると糞にしかならない。
仕様は統一性と利便性を目指すべきで、実装は後で考える、の方がいい。
仕様は追加は出来るけど、削除は出来ない。（何倍ものエネルギーがかかる）
だから、余分な仕様が入った時点で詰む。
最適化は実装にかなり依存する。そして実装は仕様に依存する。
仕様が固まっていない状況、つまり今後とも新しく仕様が追加されるのであれば、今後実装が変更される。
だから今の時点での実装の最適化を目指した仕様が入れられた場合、将来的に重荷になりうる。
(全く役に立たないもの、むしろ邪魔になっても、削除することが出来ない）
だから、private等が必要なのなら、そういうのは最適化を考えずに「必要だから入れる」でいい。
今君らがやっているクロージャごにょごにょよりは、
class C {
private var state;
constructor(state) { this.state = state }
getState() { return this.state }
}
で解決できればみんな幸せ、以上終わりだ。
もちろん今の実装でごにょごにょすれば何とかなるのなら、Class.jsとして切り出してしまうのもありだ。
（ただ動的保護は言語側のサポートがないとどうにもならないと思う）
そして実装を考慮した糞仕様になっているのがWeakMapだ。
・キーに出来るのはオブジェクトだけ
・一覧を取得することが出来ない
確かにこの仕様なら実装は単純だ。しかし仕様は汚れる。
後者は拡張方向だからまあよしとして、前者は今後互換性で問題になるだろう。（今現在は例外スローか？）
こういうところもESはよくない。仕様は仕様だけで検討するべきだ。
|
|