- ECMAScript デス 4
699 ：デフォルトの名無しさん[sage]：2015/07/23(木) 00:36:45.00 ID:UCOFR8WX - >>694
基本的に __proto__ を使っている。
Object.create()も結果的にあまり使っていない。
そもそも new もいらない子だという話もある。
実際 function の return でオブジェクトを返せるので、無ければ無いでも組める。
試しに new も使ってみたが、見やすくなるわけではない。（見にくくなるわけでもないが）
ただ、__proto__が開放されていなかったときには必要だったとは思う。
しかし __proto__ があるのなら、無くてもいい仕様だ。
prototype がいるから中途半端になっているが、実体は __proto__ によるオブジェクトツリーであり、
それをどう見せるかで色々糖衣構文が導入されているわけだが、
__proto__ で問題ない場合、糖衣構文を使う必要が無い。
実体と同じ記述の方が分かりやすいと感じる。
ちなみに俺はプロトタイプでも問題ない。（クラスでもいい)
クラスじゃないと嫌だという人にはクラス構文が必要だろうし、使えばいいとは思う。
|
- ECMAScript デス 4
701 ：デフォルトの名無しさん[sage]：2015/07/23(木) 00:48:15.61 ID:UCOFR8WX - >>695
ありがとう。参考になる。
ただ俺は5-6階層くらいで追いかけるのが面倒になって来つつある。
|
- ECMAScript デス 4
702 ：デフォルトの名無しさん[sage]：2015/07/23(木) 01:02:04.28 ID:UCOFR8WX - >>697
モジュールというのは、一応ググって見たけど、
var module = (function(){
var obj;
// 中身
return obj;
})();
ということでいいのかな？
1個でよければこれでいいけど、沢山要るのなら new 出来るようにしておかないと駄目な気が。
俺も1個のときは必ずこれだけど。
|
- ECMAScript デス 4
703 ：デフォルトの名無しさん[sage]：2015/07/23(木) 01:02:48.66 ID:UCOFR8WX - すまん、>>702 は >>696 宛て。
|
- ECMAScript デス 4
706 ：デフォルトの名無しさん[sage]：2015/07/23(木) 01:16:58.96 ID:UCOFR8WX - >>700
俺の制約は、
・chromeとFF、共に最新版でデフォの設定(flagsとかの指定なし)で動くこと。
GreaseMonkeyだからIEは不要。
旧バージョンサポートは、今の俺には無理だから最初から捨てている。
多分ES5なのだと思うが、ES6が動くのならそれでもいい。とにかくブラウザで動けばいいだけ。
俺のはかなり緩い制約だ。
君たちが別の制約でやっていて、最適策が異なるのは当然だと思う。
なお、__proto__ がES6で禁止されるのなら、それはちょっと悲しい。
Object.create({__proto__: xxx})だと、余分に1階層入ってしまうので。
|
- ECMAScript デス 4
709 ：デフォルトの名無しさん[sage]：2015/07/23(木) 01:33:01.32 ID:UCOFR8WX - >>704-705
俺はC出身だからプログラミングそのものは出来るが、
JavaScriptについてはヒヨコだし、
それ以前にOOPも真面目にやっていなかったのでリハビリ中だ。
だからCとOOPの中間のプロトタイプというのは、俺には割と居心地がいい。
書き方は見よう見まねでやっているだけ。
ポリシーをもってやっている訳ではないので、
俺の書き方自体は「ググッタらそれが出てきたことがある」位の意味しかない。
色々試しているところ。
|
- ECMAScript デス 4
710 ：デフォルトの名無しさん[sage]：2015/07/23(木) 01:44:46.71 ID:UCOFR8WX - >>708
目的は689,692に部分的に書いているが、
インスタンスの共通部分をマメに切り出して継承すれば、コード/フットプリントを削減できるんじゃないか？
しかしなぜgoogleはこれを禁止しているのだ？
ということ。クラスではなく、インスタンスツリーの継承はOOP言語では出来ないので、試してみている。
1を読む限り、このスレはECMAであれば雑談含めて何でもありだと読んだが。
> ECMA-262規格として知られる言語（通称 ECMAScript）についての利用法や言語仕様、
> その他四方山話をするスレです。(>>1)
Web製作板はIDが出ないのが問題のような気もするから、試しにこちらに落としてみた。
|
- ECMAScript デス 4
712 ：デフォルトの名無しさん[sage]：2015/07/23(木) 03:19:49.77 ID:UCOFR8WX - >>711
ありがとう。
babelというのは初めて聞いたので、ちょっとググって読んでみた。
古い書き方を学ぶ必要は無いが、そもそも俺が古いので、古い書き方でも不便を感じない。
だからこれが最大の問題かもしれない。
ただそれ以前に、何が古いのかもよく分かってないんだが。
とはいえ、新しい書き方は古い書き方の問題を解決したものであるから、積極的に試すべきだとは思う。
ES6の新機能は以下の左列の feature で全部なのかな？
http://kangax.github.io/compat-table/es6/
つついてみたら展開してサンプルコードらしきものも出てくるが、
残念ながら今の俺では何がうれしいのか分からない。MDN待ちだ。
（どういう不便さを解決できる書き方なのかわからない）
とにかくbabelが先行しているのは事実のようだが、
それ以前にES6のおいしさを俺が理解できないのが問題だ。この点は申し訳ない。
ちなみに、基本的に面倒でも書ける物は何とかなるので、糖衣構文にはあまり興味が無い。
本質的な拡張（それが無いとどうしようもないもの）ってどれだか分かる？
Proxyとか、ObjectのハッシュキーをObjectにできる（Map）はそれなので、Built-insにあるものが全部かな？
|
- ECMAScript デス 4
717 ：デフォルトの名無しさん[sage]：2015/07/23(木) 21:33:34.18 ID:UCOFR8WX - >>713
> Babelが対応してないのは処理系の対応が必要な本質の拡張だと思っていい
なるほどありがとう。これは賢い見分け方だ。(babelが完成しているという前提だが）
> class構文はArrayなど組み込みクラスを拡張する唯一の方法なのでただのシンタックスシュガーではない
いやただのシンタックスシュガーだという話だが。どこまでがその範囲かという話の気もするが。
http://js-next.hatenablog.com/entry/2014/11/01/034607
ただ、class構文の方が見やすいのは認める。
|
- ECMAScript デス 4
718 ：デフォルトの名無しさん[sage]：2015/07/23(木) 21:36:01.95 ID:UCOFR8WX - >>714
> JSって言語としてはプロトタイプベースでも、処理系はクラスベース前提に最適化してるから、
この判断がそもそもおかしい。(hidden classについて君が勘違いしているだけかもしれんが。後述）
プロトタイプベースをクラスベースで処理して最適なわけがない。どうやってもオーバーヘッドが生じる。
（実装としては大して変わらないというのはさておき）
ただ、クラスベースで書かれた物についてはマッチするし、実際にこれも多いだろう。
つまり、問題はJavaScriptエンジニア自身がプロトタイプを使いこなせていない点にある。
使いこなすに値するかは別の問題だが。
クラスで出来なくてプロトタイプで出来るのはインスタンスツリーで、これは今試している。
後はやはり動的継承だが、これについては今のところやりたい局面が無い。
|
- ECMAScript デス 4
719 ：デフォルトの名無しさん[sage]：2015/07/23(木) 21:36:40.04 ID:UCOFR8WX - >>714
V8についての記事を少し読んでみたが、hidden class はクラスベースの最適化を目指しているのではなく、
プロパティアクセスを高速化するためにオブジェクトを静的構造体にして決め打ちにするためだ。
このとき、どの構造体なのかを判別するために使っている。
クラスベースのJavaScriptのためではない。内部的に各オブジェクトを各クラスとして扱っているだけだ。
https://developers.google.com/v8/design
http://jxck.hatenablog.com/entry/20111110/1320883625
>>715-716
プロパティアクセスについてはMSDNに書いているとおり、最初に全部まとめて作って後で追加しなければ最適化がかかる。
V8でも同じような仕組みで高速化しているだけの話だ。
（ただ、本当に全面的に hidden class の実装にした場合、常に静的構造体アクセスになるので、
後からいくら追加/削除/型の変更をしてもアクセスそのものは遅くならない。
遅くなるのならそういう実装ではないということになる。
ただ、最適化についてはエンジンに依存するが、いちいちこれを言い出したら面倒なので通常は省かれている。
だからその話もV8では対策済みなのかもしれない。）
https://msdn.microsoft.com/ja-jp/library/windows/apps/hh781219.aspx
>>716
全面的に hidden class の実装なら、
オブジェクトリテラルで書いても、あるいは、どういう書き方をしても、 hidden class になる。
|
- ECMAScript デス 4
720 ：デフォルトの名無しさん[sage]：2015/07/23(木) 21:37:51.54 ID:UCOFR8WX - >>715
指摘はその通りだ。
しかし、俺はもう既にgoogleを信用していない。だからgoogleが言っている事は鵜呑みにしない。
googleのエンジニアの質も相当に低い。
理由はあっちのスレにも書いたがGCの件だ。
JavaScriptにおける循環参照その他の「使い方によるメモリリーク」は全て対策されているようだ。
つまり、全てブラウザのバグだったということだ。
エンジニアの数は JavaScript>>>>googleのV8チーム なのだから、
世界レベルで最適化するのであれば、最初からV8が対応すればよかっただけの話だ。
メモリリークが問題になるほどの状況になったら、遅いけど完全なGCで回収すればよかった。
これは再帰で組めるので、100行程度で実装できる。
それをせず、世界中のJavaScriptエンジニアに醜い対策コードを書かせるという判断を下したgoogleは技術力が低い。
だから、彼らの判断は信用に値しない。
実際にインスタンスツリーを構成すると、クラスツリーと同程度の見にくさ以外の問題点は無い。
見にくさだけを問題として「止めとけ」というのならクラスツリーも止めるべきだ。
（これはクラスシステム全否定になるから出来ないとして、
だとすると、クラスに慣れているエンジニアにとってはインスタンスツリーも問題ないはずだ。）
ただ、俺がまだ気づいていない問題点があるのかもしれない。だから聞いている。
言い換えれば、俺が無知なだけか、googleの判断ミスかを確認しようとしている。
説明を理解できないのは俺の問題だが、説明が出来ないのはgoogleの問題だ。
googleの言及は見やすさだけだ。ならばコード/フットプリントを優先するならやってもいい範囲だと俺は判定する。
実際にクラスシステムは同様に見にくいのだから。
|
- ECMAScript デス 4
724 ：デフォルトの名無しさん[sage]：2015/07/23(木) 23:00:40.95 ID:UCOFR8WX - >>721
それは多分間違いだ。
理由は、new だけをターゲットにするのなら、この構造は明らかに不適だからだ。
new の場合は最初からメンバが全面的に決まる。
つまり、C0,C1と継承していくのではなく、最初からC1を作る方がいい。しかし、そうなっていない。
> https://developers.google.com/v8/design (再掲719）
また、classなら、後からプロパティが追加されることもほぼ無い。
この「後から追加されない」前提なら話がすごくシンプルになるので、これを利用しない手は無い。
この場合、普通は、後から追加されればシンプルに「捨てる」という実装が取られる。
実際は、z というプロパティを追加したら、新たに hidden class が生成されている。
> http://www.html5rocks.com/en/tutorials/speed/v8/?redirect_from_locale=ja
もし本当に new のときだけ hidden class を使用するにこの実装なら、間抜けすぎる。
googleは糞だという判定ではあるが、さすがにそこまではひどくないと見ている。
実装自体は全面的に hidden class を使う気がある感じだ。
もしこの実装で本当に new でしか使えないのなら、それはバグっていてリリースできないだけだ。
>>723
> んなもん散々検証して判断してるに決まってるだろうが
これは何をやったんだ？ベンチマークか？
new の場合とオブジェクトリテラルとの速度比較で検証は出来るが。
|
- ECMAScript デス 4
725 ：デフォルトの名無しさん[sage]：2015/07/23(木) 23:42:47.23 ID:UCOFR8WX - 訂正
× つまり、C0,C1と継承していくのではなく、最初からC1を作る方がいい。
○ つまり、C0,C1,C2と継承していくのではなく、最初からC2を作る方がいい。
>>721
ちなみにその他の実装面については俺は同意する。
オーバーヘッドはそこそこあるだろうし、
クラスベース記述が先に最適化されることも妥当だろう。
JavaScriptの世界でクラスベース記述が標準なのかは俺は知らない。
|