JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/12/07(月) 07:26:33.87

実際にJavaScriptを書いている人の情報交換所です。
プログラミング既習者専用です。初心者の方はご遠慮下さい。
玄人の方、歓迎致します。

**デフォルトの名無しさん** · 2015/12/08(火) 09:14:10.74

保

**デフォルトの名無しさん** · 2015/12/08(火) 09:14:58.16

守

**デフォルトの名無しさん** · 2015/12/08(火) 21:57:28.55

>>8
ありがとう。了解した。
とはいえ予定は7の通り。

**デフォルトの名無しさん** · 2015/12/11(金) 22:17:41.43

>>8
EMCAスレが落ちているのを確認した。
10スレ未満は丁度1週間で落ちるようだ。

それはそうと、現実問題として上級者がJavaScriptにはいない（いにくい）のかもと思うようになった。
元々は単なるヘルパースクリプトで、質問スレ見ても分かるとおり、単発の修正とかに使われていた。(はず）
今なら「PHPでやれ」と回答すべき案件等と言えば分かりやすいか。
Ajax以降は必要となれば大型化するが、クライアント側に大型データ構造を持つ使い方は自然ではない。
MMORPG等をWebGLで実現するにしても、クライアント側は描画に徹してデータはサーバ側に送るのが普通だ。
だから内部構造にこだわるべき中級者以上が育たない（必要ない）環境なのかもしれない。
あるチームでサーバクライアント型アプリ（ゲームでもチャットでもいいが）を作るのなら、
サーバ側に実力者を振り分けなくてはならないのは自明だ。

とはいえ、出てくるかどうか待ってみることにする。
ググれば分かるとおり、奴らはQiitaが好きみたいだが、俺は匿名の方がいいと思っているので。
とはいえ、匿名掲示板はどうしても雑音が多すぎる。
彼等がQiitaのほうを好むのなら、いくら待っても空振りで終わる。
それでも俺は試してみるが、盛大に空振りするかもしれないのでそのつもりで頼む。

**デフォルトの名無しさん** · 2015/12/13(日) 21:10:31.93

JavaScript 「再」入門 - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript

**デフォルトの名無しさん** · 2015/12/15(火) 20:58:50.84

ECMAスレに居た人と実際にコードを書いてる人は層が違うと思うけどな。
言語仕様を愛する人と、WebAPI技術を愛する人と、フレームワークを愛する人は違うだろうし。

**デフォルトの名無しさん** · 2015/12/15(火) 22:49:00.04

>>14
ああ、あれは明らかに違う連中だ。少なくとも俺と同じ側ではない。

プログラミングなんて本来は手段、従ってプログラミング言語は包丁であって、
もちろん包丁職人やコレクターもいていいが、道具として使う料理人が一番多いのが普通。
しかし彼等は異様に細部にこだわっている。彼等は何者だと思う？

そもそも仕様仕様とうるさいのだが、仕様の細部なんて使わないのが普通だと思うのだが。

Q. String が期待される関数 function func(str) に対して Array が与えられた場合はどうするべきですか？
A1. 当然暗記している型違い時の変換規則を活用し、適切に対処します。
A2. それはただのバグです。

型付き言語だとそもそもA1はコンパイルが通らない。
俺は型付き言語出身だから、当然A2で組んでいる。使う予定のない変換規則なんてどうでもいい。
ところが彼等はこれじゃ駄目だと喚く。
でも具体的にどう活用すればメリットがあるのかは示せない。
何なんだよいったい、と思う。

ところで連中は立て直さないのかな？

**デフォルトの名無しさん** · 2015/12/15(火) 23:46:05.86

>>15
それはダックタイピング系のことをちょっと大げさに捉えすぎて無いかい？
それと引数の型についての選択肢としては
A1.何も気にしない
A2.極力活用するよう努力する
A3.型チェックをしてエラーとする
の３つだろう。
例えばpromptの返り値のstrに対する処理をコードにするとこう
A1. str.slice()
A2. (str||'').slice()
A3. if(typeof str!=='string')throw 'No!';str.slice()

で、
A1派は、メソッドを持っていればそれで処理をさせて問題ない。
null等は自動的にエラーになるのでちょうどいい。

A2派は、どちらにしろ空の値はpromptをやり直したり別途特別な処理するんだろうから
nullなど無効も極力エラーは出さず空の値と評価してやるくらいがちょうどいい。

A3派は、来て欲しい型でなければエラーとするのが最も安全。

というような主張だろうが、君はどんな主張で、どんな主張に納得してないの？

**デフォルトの名無しさん** · 2015/12/16(水) 00:04:47.52

また型が把握できる場合と、何が来るか本当にわからない場合では当然スタンスが違うと思う。
後者でいうと、Stringが期待される場面でArrayが来た場合なんてどうしようも無いだろうが、
Arrayを期待する場面なら他のArrayLikeなオブジェクトもArrayとして見てやるべきじゃないかという論になる。

そこで、また派閥が分かれるだろう。
何もしないまたはエラーとする（Array.isArray）（Arrayだけしか面倒を見ないから）、イテラブルだけ面倒見る（[...arg]）か、
多くのArrayLikeを面倒見る（Array.from(arg)）か、何もしないまたはエラーとする（例えArrayに変換できなくともArrayのメソッドを持っていればよい）
また、配列の使い道によっては@@isConcatSpreadableを考慮するかどうかも問題になってくるだろう。

**デフォルトの名無しさん** · 2015/12/16(水) 00:25:57.22

まあ本当にそっち系の人はこんなもんじゃないか。
Object.prototype.toString.call(arg) == '[object Array]'
とArray.isArrayの違いとどちらが適切かを語るレベルまでいけば一人前か。

まあ彼らは意味に敏感なんだろう。
配列を期待するといっても、配列はいろいろあるし、期待の仕方もいろいろある。
なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。

**デフォルトの名無しさん** · 2015/12/19(土) 02:38:04.74

都合上、>>7の前スレの内容を先に全て落とす。
以下4投は転載。

**前スレ4** · 2015/12/19(土) 02:38:56.06

とりあえず俺が話したい項目を挙げておく。
気になる物があれば勝手にレスを付けてくれ。
もちろん他の誰かが勝手に始めてくれても構わない。
俺も気になれば勝手に参加するし、どうでもよければ無視する。

使い方は基本的に他のスレと同じ、ただし初心者お断り、だ。

**前スレ5** · 2015/12/19(土) 02:39:25.80

・コーディングストラテジー
http://peace.2ch.net/test/read.cgi/hp/1444186237/550
http://peace.2ch.net/test/read.cgi/hp/1444186237/562

JavaScriptに於けるコーディングストラテジーだが、単純には以下2つのどちらかだと思われる。

α. 安全重視、全箇所で型/値チェック。
β. 簡素化重視、最初に型チェック、以降は「型」までは確定、値については保証無し。

αは関数単位で抜き差しが可能。その点機能の追加/削除は楽だ。
各関数は型判定等を持つため複雑になるが、安全領域を管理する必要がない。

βは期待される型以外では何も考える必要がないため、その分関数の仕様が小さくなり、
デバッグが楽でバグも出にくく動作も速くなる。ただし、型チェックを既に通っているかを管理する必要がある。
ネットワークに於けるファイヤウォール内/外の管理のようなものだ。
基本的に関数毎の抜き差しはできない。型チェック部分＋動作部分のセットでやらないと駄目だ。
だから関数単位での粗結合化はできない。

俺はβでやっている。
そして現実的にはβしかないように思えるのだが、どうか？
可能であれば直接本職の方々の意見が聞きたいが、
JavaScriptはソース見放題だから、企業のサイトのソース（=本職製）からの類推でもいい。
ダックタイピングを生かすのなら多分αじゃないと駄目なのだが、
俺は型システムに慣れているというのもあって、今のところダックタイピングの利点を感じられない。
αだと各関数で様々な型を処理しなければならず、これがバグの元になるので、
最初からStringならStringと決めうちで各関数を用意、Stringしか入力されないように上位階層で対応している。

**前スレ6** · 2015/12/19(土) 02:39:52.02

・プロトタイプの活用
静的クラスでは出来なくて動的プロトタイプでは出来ることを使って、何かできないか。
今思いつく中では、以下がある。
A. 動的プロトタイピング(__proto__の頻繁な変更）
B. インスタンスツリー
C. 親への透過的アクセス（親に動的に追加されたプロパティに対する透過的アクセス）

Aは変更自体はやっているが、頻繁に変更する需要がないのでそれ以上試していない。
Bは現在試しており、見にくくなる以外の弊害はない。見にくさについてはデバッグ用環境を整えて対応した。
メリットはフィールド共有によるフットプリント削減だが、
しかしこれはあらかじめ共有すると分かっていれば静的クラスでも出来る。
デタラメに共有したりしなかったりする場合も、
共有する派生クラスと共有しない派生クラスを用意すれば、静的な場合は対応可能になる。
従ってどうしてもというのならやはり動的なものに限られてしまうのだが、これは需要がない。
Cは試したいところだが需要がない。

従って、仕様としては出来るが、実際の需要がなく、活用できていない。
他の活用案もあれば是非。

**前スレ7** · 2015/12/19(土) 02:40:19.96

・ダックタイピングの活用
共通基底クラスを持つ場合、当然ポリモーフィズムできるとして、
ダックタイピングの場合は、共通基底クラスを持たなくても、共通の名前のメソッドがあればポリモーフィズムできる。
だからといっても、活用案がないので、事例があれば是非。

**デフォルトの名無しさん** · 2015/12/19(土) 02:41:08.31

以下、全て>>16の定義で。

>>16
こちらは基本A1で組んでいる。初段はA2もあり得る。
理由は>>21のとおり、入力段で型を確定させる方が楽だと判断しているから。

JavaScriptの場合、型が確定しないのはDOMか鯖からの入力に限られる。
だから最初の段で型を確定させ、以降は型確定で組んでいる。
この場合、型確定エリアと型不確定エリアが明確に分離されるので、型確定を忘れるとおもむろにバグる。
しかしこれは前述のように限られており、見落としたりする心配はほぼ無い。

型を不確定のまま伝搬させるのは余計に難しい。だから通常あり得ない。
となるとA2/A3が必要なのは「どこから呼ばれるか分からない」という関数だけになる。
（型不確定エリアからの直接呼び出しがあり得る）
これについてはプログラムを見てそういうことがないように確認すればいいという事にしている。

というわけなのだが、どうかね？
A2/A3は関数の機能としてはA1のスーパーセットになる。型が予想外の時の分だけ仕様が大きい。
だからA1で組んでしまうのが楽だ。問題は見落としがある可能性が残る点。ただし、これは見やすい。
A2/A3の場合は見落としは考える必要はないが、
個々の関数が全ての型について設計通り動くことが求められるので、
テスト項目が多くなり、またバグを誘発しやすいと見ている。

ちなみに、「何が来るか分からない時でも正常動作」というのは、考えていない。
というか、その時はバグっていいという判断だ。
・入力が明確に間違っている場合、再入力を求める。誤入力状態での表示はどうでもいい。
・Ajax結果が不正の場合、リロードする必要がある。このときも表示はどうでもいい。
所詮はヘルパースクリプトだから、この辺で留めている。

**デフォルトの名無しさん** · 2015/12/19(土) 02:42:15.14

>>17
それはダックタイピングだと思うが、正直俺はその点に関しては気にならない。
期待通り動けば何でもいい。
気になる人は例えばtoString()の解釈について、
・ダックタイピングだ。toString()があるから使えるだけ。
・各型についてtoStringというインタフェースが実装されているのだ。
・toString()はテンプレート関数で、各型についてオーバーライドされているのだ。
と考えることが出来るかもしれないが、俺はどれでもいいと思っている。
JavaScriptはthisを関数側に持たせているため、callを使って他型のprototype等を間借りすることが出来る。
これは便利ではあるが、しかし真面目にインタフェース等で実装すれば済むことが大半だ。
だからこの方式もthisがいちいちはがれてbindしなければならない方が面倒だ。
classシステムのようにインスタンス側にthisを持たせる方が理に適っているように思う。

**デフォルトの名無しさん** · 2015/12/19(土) 02:42:41.90

Array.from()を実装したとして、それがどこまでの範囲で使えるのかは「使う側が確認する必要がある」とする。
つまり、callで突っ込むのは勝手だが、ちゃんと動くかは「確認しろよ」ということだ。
その手の動作範囲を広げていくのは、YAGNIとかKISSとか言われるらしいが、大体無駄に終わる。
だからArray.fromの実装側は自分が使う最小限に留めて良く、間借り側が正常動作を保証しろと考える。
これはおそらくJavaScriptの思想とも合致している。
ArrayのメソッドはgetElementsByTagName等で返されるCollectionに対しても大体動作するが、
動作の保証はしていない。
つまり、間借り側(Collectionでcallする側）が正常動作を保証（確認）する必要がある。
クラスシステムの場合、実装してあれば確実に動作するし、実装していなければ動作はしない。（間借りも出来ない）
JavaScriptの場合は、使えそうなら使ってねといういかにも曖昧な感じで、それでいいのか？という疑問はあるが、
上記のように、「バグってたらリロードでおk」ならこの方が色々楽なのは事実だ。

結局の所、出自が（というよりも今も大半の用途でも）チョロスクリプトなので、それ向けに仕様がチューニングされている。
これで大規模なプログラムを組むのがそもそも無理がある、ということなのだとは思う。
チョロスクリプトとして使う分には、なかなか面白い仕様だと思う。

**デフォルトの名無しさん** · 2015/12/19(土) 02:43:14.27

>>18
それは同じだと思うが、違うのか？
=== なら以下にポリフィルとしてそのまま記載されている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray
== の場合もその場合は危険性がないように思える。
ただし、これについては俺は真面目にやってないので自信はない。
ただ、そもそも「文字列との比較は === 」というのが lint で引っかかるので、常にそうすればいいだけだ。

> なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
これはあると思う。
あれだけ仕様が小さくて頭の中に入りきるサイズだから、というのはかなりあると思う。
C#やJavaなら調べながらのコーディングになるので、気にしてられない。

**デフォルトの名無しさん** · 2015/12/19(土) 04:44:14.14

>>26
問題はArrayが少し変わったオブジェクト程度であること
そしてArrayのメソッドは、ArrayLike（この場合lengthを持つもの）について保証していて最初からそのように作られている
JSにおいて配列の最も基本的な定義はlengthプロパティに要素の長さを記録しているもの程度のことでしかない
当然DOMの配列でも動くし、型付配列でも動く
それなのにわざわざArrayだけでしか動かなくする必要があるのか？

ここがミソで、わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
Array.isArrayは型付配列すらtrueを返さない
isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ

配列を扱うとする関数でArrayだけに絞るのはJSにおいて必ずしも十分ではないということだ
その関数を作る目的と使われるシチュエーションを考慮しないといけない

>>27
@@toStringTagをお忘れかな？
===の件もそうだな
どうして必要もない制限をわざわざするのか？と思ってしまう
というのは半分ウソで、実際は他の演算子と文字数が違うものを基本で使うのは気持ちが悪いから==を基本で使う
経験上==を基本で使ったからといってバグになるようなことはない
型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから

**デフォルトの名無しさん** · 2015/12/20(日) 00:52:32.40

>>28
> そしてArrayのメソッドは、ArrayLike（この場合lengthを持つもの）について保証していて
> isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ
これは「isArray は Array.prototype の動作を保証するかどうかを返す」と考えていいのか？
これならまあ使える仕様だ。

ちなみに確認したが、DOMのCollectionについては isArray は false になる。
実際の所、このCollectionは無理矢理Array的アクセスが出来るように見せかけただけのものであり、
書き換え不能にしてあるから、例えば Array.prototype.splice.call(DOMのCollection,1,1) は（エラーを返さないが）動作しない。
だから辻褄は合っている。
まあ正直、「動作しないのならエラー返せよ」と思うが。以前はまった。

> @@toStringTagをお忘れかな？
ああこれは知らなかったからだね。
これも自然な仕様だが、だとするとMDNもちょっと書き換えたほうがいい気はするが。

**デフォルトの名無しさん** · 2015/12/20(日) 00:53:42.58

> 経験上==を基本で使ったからといってバグになるようなことはない
> 型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
まあ実際はそうなるはず、というかそれを目指して型変換規則が作られているはずなので。
実際のコードを見ると、==派と===派は半々という感じか。
一応googleのコーディング規約には === を使えと明記されていたはずだが、今見ると無い。
削除されたか、或いは俺の勘違いかだが、しかし日付を入れてないからどっちか分からない。
https://google.github.io/styleguide/javascriptguide.xml
この手のドキュメントのリリース日が辿れないってマジで馬鹿なのかあいつら。
というかこの辺で色々文化が違って無駄にストレスが溜まる。

俺は見た目はどうでもいい派なので、文字数の違いとかは気にならない。
俺が組んだところは基本的に === でも動くようにしてあるので、全部書き換えてもほぼ問題ないはず。
実際は歴史的経緯で混在しまくり、今更書き換えてデグレードするのは避けたいので、放置している。
ただJavaScriptの本来の設計は == なのだと思う。
（基本 == で、真に必要がある場合は === で)

**デフォルトの名無しさん** · 2015/12/20(日) 00:54:09.55

とはいえ、実際の所、他言語だと「潜在バグ」を嫌うので、===推奨になるのも分かる。
というか、おそらくそちらの方がプログラミングとしては正道だ。
JavaScriptの仕様は、「チャキチャキ作ってサクッとリリース」向けであり、「バグがないプログラミング」向けではない。
とはいえ、Webにはこれが正しいのも事実。
マイナーバグに対する作り込みでリリースが遅れるくらいなら、
バグがあってもクリティカルでないのならリリースした方がWebにはいい。
相手は「今欲しい機能」を求めているのだから。
逆に「バグのないプログラム」を目指すのなら、基本===ベースで行った方がいい。
相手は「将来欲しい機能」を求めていて、そこにバグがあっても困るという人だから。
ここら辺は置かれた状況の違いで文化の差異が発生していると考えている。

> わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
これが典型で、「100%動く保証」が必要か、「99%動けば問題ない」とするかだ。
見た目動いているからいい、を是とするか非とするかとも言える。
テストで100%網羅できることはない。
バグが無いことを目指すのなら、対応している事が確認できなければ使えない。
Array.isArrayでそれが確認できるのなら、それは使える仕様だ。

**デフォルトの名無しさん** · 2015/12/20(日) 00:54:39.34

@@toStringTagの件でも思ったが、まだ「ローカルプロトタイプ」は出来ないのか？
クラスシステムモドキで頑張っているようだが、元々prototypeを拡張するように設計されており、
実際の所、それの方がどう考えても使い勝手がいい。
だから、prototype.jsが流行ったというのも分かる。
問題はプロトタイプ汚染が発生することで、
逆にいえば、ローカルプロトタイプが規定できて汚染が発生しないのなら、おそらくそっちの方がいい。
とはいえ、今でも手動で __proto__ 等を使って設計できそうではある。
誰もこれをしないのはまた別の問題があるのか？

jQueryにしてもバージョン混在の問題があり、もちろん回避策もあるわけだが、
そもそもjQueryをローカル読み込み出来れば問題なくなるはず。
システム的にはスコープチェーンを辿っていく方式なので、
関数単位でのローカルプロトタイプは出来るように思えるが。

@@toStringTagについては、誰かが書き換えた影響が自分にも出る可能性があるということだと思うが、
この手のプロトタイプ汚染っぽいものを言語的に排除できるようにして、
prototypeを自由に拡張するのが本来のJavaScriptの思想だと思うのだが。

元々一人で組むチョロスクリプト用だからその機能がなかったのは仕方ないとしても、
無理矢理クラスにしようとしていて手こずっているように見える。
ローカルプロトタイプの方が多分この言語的には似合うだろう。
誰もやろうとしていなさそうなのは、何か別の問題があるのかな？

**デフォルトの名無しさん** · 2015/12/20(日) 04:56:15.02

>>29
無理やりArray的アクセスが出来るように見せかけただけのものというより、
DOMのコレクションはそれはそれで立派なArrayとは違う配列。
そしてslice等の破壊的メソッドが通らないのは、見せかけだからではなく、
凍結された配列だから破壊的操作を受け付けないから。（エラーは返す）
>>32
プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
それすらもES6モジュールで分離すれば解決するだろう。
それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
インスタンスベースと見た時のJSの思想だと思う。

**デフォルトの名無しさん** · 2015/12/21(月) 01:11:35.42

>>33
ふむ。もう一度確認してみたがエラーにはなるようだ。
確認してから書いたのだが、どうやら間違っていたらしい。すまん。

> それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
> インスタンスベースと見た時のJSの思想だと思う。
多分これは違う。
> 自由に「.prototype」を拡張する
これでは既存のクラスシステムと同じだ。
「自分で型を作れる」または「『新規の』型を自分で作れる」だけに過ぎない。

JavaScriptのプロトタイプベースは、「既存の」型を拡張できるところが違う。
ただこれを活用できるかはまた別だ。
これはMDNでも紹介されている。
> これはとても強力です。
> JavaScript では、プログラム上でいつでもどれかのプロトタイプを変更することができます。
> ということは、実行時に既存のオブジェクトに対して追加のメソッドを加えることができるのです:
> （中略）
> これは Person オブジェクトをデバッグするときに役立ちます:
> https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript
ただしデバッグ時以外に活用する方法を誰も思いついていないのだと思う。

**デフォルトの名無しさん** · 2015/12/21(月) 01:12:01.84

ある実行中のJavaScriptがあって、それに対してevalでprototypeの変更を行えば、
仮に鯖上で実行中であってもいきなり動作を変えられる。これは他の言語では出来ない。
XenやVMWareがやっているようなライブマイグレーションを言語がサポートしている。

ただそんな機能があっても現実的には必要ない。
サーバーを一旦落としてデバッグ済みのソースに切り換えるのが今の通常の方法だ。
どうしても落とせないところは、今は上記のようにハードウェアレベルでライブマイグレーションができる。
だからソフトウェアレベルでのライブマイグレーションは必要ない。

一応文法的にもprototypeを拡張する方向で出来ている。
クラスに対して色々な書き方があるが、好みはあるとしても、
文法的/構造的に一番無理なく書けるのは prototype への直接差し込みだ。
だからMDNでもその記法で書かれている。
元々 prototype を拡張しながら使うように設計されているので、当然ではあるのだが。
> var Person = function (firstName) {
> this.firstName = firstName;
> };
>
> Person.prototype.sayHello = function() {
> console.log("Hello, I'm " + this.firstName);
> };
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript

**デフォルトの名無しさん** · 2015/12/21(月) 01:12:28.39

> プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
> それすらもES6モジュールで分離すれば解決するだろう。
しかし@@toStringTagの件はそれだろ？
俺は「そんなの書き換える奴が悪い」で終わりだが、
それが許されないから ==='[Object Array'] では駄目で Array.isArray なんだろ？
ただ import で自由にビルトインも含めて拡張できるのであれば、
上記「禁忌」とされてきて開かずの扉になっている部分を、誰かこじ開けるかもしれない。

**デフォルトの名無しさん** · 2015/12/21(月) 05:09:36.07

==='[Object Array'] では駄目で Array.isArray は良いとかではなく、
@@toStringTagを考慮してあげるか、そこまでしないかの差だというつもりで差があると言ったんだよ。
そもそもisArrayもProxyは通すからね。別にisArrayに通ったからといってそれがArrayの動作をすることまで保証されていない。
起源がArrayだという程度の意味しかない。
それで十分な場合も多いと思うが、より良い配列の判定がある場合も多いという話がしたかったのだよ。

あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
そういった行いを尊重しようとするか、しないかの判断ではないかな？
それとprotoypeというのはあくまでnew演算子が活用するだけのものであって、
それ以外に特別な意味はないし、プロトタイプベースの一角でしか無い。
一番大事なのはプロトタイプを変更できること。

それと動的変更は別に動いてる最中ではなく、変更をかけてから動かすという方が主だろう。
コンパイル言語ではなく、Web上で不規則かつ非同期にいくつものスクリプトが読み込まれ実行されるものなので、
何かを拡張したりするには、実際に動きながらするのが最も妥当な方法だ。

**デフォルトの名無しさん** · 2015/12/23(水) 00:27:11.83

ここは「言って欲しい意見」を期待できるところではない。それは諦めろ。
さすがにそれだと本当に書いているのか疑問だ。
色々ツッコミどころはあるが、一つずつ行こう。

> あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
> そういった行いを尊重しようとするか、しないかの判断ではないかな？
ビルトインの@@toStringTagの書き換えを尊重する場合って、具体的にどんなケースがあるんだ？
俺はこれはコーディング規約で禁止にされるべき項目だと考えている。

**デフォルトの名無しさん** · 2015/12/24(木) 07:58:45.60

>>38
「言って欲しい意見」を期待とはどういうことだ？
そちらがこちらの話した意図を正しく捉えて無かったようなので補足したまで。

そしてコーディング規約で禁止とかいうのが考え方狭すぎだろう。
JSはハックやパッチにも使うもの。
Arrayの@@toStringTagを書き換えたのなら、それ自体がほぼ目的の
それはArrayをStringTagで判定しているところに通さなくしたいというケースも有るだろうし、

一方大規模開発でStringTagに追加でメタ情報を付与して活用しようとするケースも有るだろう。
例えばArrayのStringTagを"Array:Any"とかにして、
int8型配列のを"Array:Int8"、他の自作配列を"Array:Hoge"にし、
デバッグや補助関数で活用するということも出来るだろう。

**デフォルトの名無しさん** · 2015/12/24(木) 18:11:12.05

まあ自分が今回JSらしさとかtoStringTagらしさをどのように語っているのかというと、
仕様の定義に根拠を置いているんだよね。
緩いJSとは言え本当にすべきでないようなことや悪いことは仕様で禁止されている。
逆に禁止されていないのであれば、原則活用することは罪ではないと考える。

例えばtoStringTagはWritableがfalseだから通常無意識に書き換えられるようなものではないが、
Configurableはtrueなので強い意志があれば書き換えて良いものとなっている。
一方コンストラクタのprototypeプロパティはConfigurableがfalseだ。
これはJSにおいてprototypeプロパティのないコンストラクタはコンストラクタとして最低限成り立たない、
もしくはprototypeプロパティのないコンストラクタはJSらしくないからだ。
こういった改変をしようとするのは悪だと考える。

まあ互換性によって残っている良くない仕様というのもあるので、全て価値観を仕様に頼って良いわけではないが、
toStringTagなんてものはES2015において新しくよく話し合われて入れられたものであり、
その様々なシチュエーションで使えるようにしてくれた意志は尊重すべきだと思っている。

これが土台で、勿論その上に事案毎にコーディング規約やらが来る。

**デフォルトの名無しさん** · 2015/12/26(土) 19:51:45.07

「Microsoft EdgeのJavaScriptエンジンを、ChakraCoreとしてオープンソース化する」

Windowsがオープンソース化される予兆 - 阿久津良和のWindows Weekly Report | マイナビニュース
http://news.mynavi.jp/articles/2015/12/21/windows10report/
2015/12/21

**デフォルトの名無しさん** · 2016/01/10(日) 21:23:23.77

具体的なコードをもとに話を進めてくれないと、
何がやりたいのかさっぱりわからない
文字数は出来るだけ切り詰めて原則箇条書きとかね
一般論をダラダラやられても困る

**デフォルトの名無しさん** · 2016/01/12(火) 17:09:01.34

適当に例を挙げての具体的な話などしても意味は無い
具体的であればあるほど答えは誰が見ても決まってるのだから
そもそもその手の人達が一般的にどうしてそういう行動するのか共感ができないというから
その原理と一般的な信条、思考パターンを述べる展開になっている

**デフォルトの名無しさん** · 2016/02/08(月) 22:51:41.45

C言語信者な元ゲームプログラマーで今有明海の漁師です。
C言語信者なのは、スピード命！スクリプトとかCPU資源浪費しすぎだろ！
って思ってるから。
そんな私が、手持ちAndroid７インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。

凄え。。。
Javascriptでなんでもできるじゃん・・・まじかよ・・・
Androidアプリ書こうかと思ったけどJavascriptでいいわ。
PCからも見れるしね。
まだ航跡記録とかマーカー記録とか作ってない中途半端な状態だけど
休みの日に酒飲みながら機能追加していくの楽しすぎるｗ
http://www13.plala.or.jp/tarna/maps/ariakekai/index.html
有明海を見てね。
長崎県と熊本県の間の内海です。

44 · 2016/02/08(月) 23:02:40.71

あ、ちなみに、表示してる緯度経度は日本測地系です。
漁業用のGPSが今もみんな日本測地系を使ってるので。
携帯もスマフォもGoogleMapも世界測地系なので変換してます。

**デフォルトの名無しさん** · 2016/02/09(火) 23:20:54.03

>>44
見た。
てか、きっちり書いてあるなあ。

Cから見ればJavaScriptなんて超大富豪プログラミングだからね。
ただ、JavaScriptのユルさはなかなか良いとは俺も感じる。
ブラウザでお気軽GUIできるのもいい。

とはいえ、その規模で収まっているうちはいいが、
これからバシバシ機能追加していくのなら、JavaScriptのアレな点が見えて嫌いになるかもw

**デフォルトの名無しさん** · 2016/02/10(水) 09:11:00.33

>>46
JavaScriptは今じゃ、ブラウザの言語でとどまってないからね。

１．Electronでマルチプラットフォームアプリを作成できる
２．CordovaでiOSやAndroidアプリを作成できる
３．Node.jsを使って、Raspberry Piのようなハードウェア制御ができる
４．同じくNode.jsを使って、PHPの代わりにサーバサイドの制御ができる

１粒で５度美味しいプログラミング言語です。緩いが故に大変な部分も
あるけれど、基本的にはライブラリを活用する事でその辺を軽量化でき
るしね。

**デフォルトの名無しさん** · 2016/02/11(木) 01:04:16.07

>>47
嫌いな人も多いが、俺もnodejsの便利さにいまさらびっくりしてる。
eureca.io使って、クライアントとサーバが双方まるで直接呼んでるみたいにfunction呼び出しして、あまつさえコールバックまで出来るとは、とビビるくらい。

**デフォルトの名無しさん** · 2016/02/11(木) 09:19:41.38

>>48
言語の弱点をライブラリ群がカバーしてくれてるから、助かるよね。
支持されていなかったら、そのライブラリ達もいないわけで。

**デフォルトの名無しさん** · 2016/02/11(木) 16:07:05.01

>>49
あとは、プロトタイプベースで魔改造する余地があったのも大きいのかも。
普通の言語で、基底クラスを基底クラスのままメソッド追加するとか、上書きする、なんて今までの言語では頭おかしいって言われそうなユルさかつ、
言語仕様としてシングルスレッドじゃん→なんかコールバックさせる仕組みを外に持たないとね→実装
みたいな魔に魔を重ねた改造の結果、使いやすくなってるような気がする。

44 · 2016/02/12(金) 01:30:54.19

>>46
距離を計算するGoogleMapsライブラリに
グローバルで保持してる中心座標を渡したらエラー。。。
new 座標（global中心座標）して渡したら通る。。。どういうこと？

っていうか、渡す時も、受け取る時もnewしないとエラーが出ることがあるんだけどなんだこれ・・・
javascriptの仕組みを理解できてないね・・・orz

newで受け取った値を代わりに使ったら、前の値はメモリに残るだろうし
ガーベージコレクションは自分でしないといけないのかなぁ。
富豪だし無視してもいいかなぁｗ

もうちょっと遊びながら勉強してみます（汗

**デフォルトの名無しさん** · 2016/02/12(金) 08:43:48.25

>>51
new Dateと同じだろ。

日付に見えてただのテキスト型になってるとかそういう事。なので、明示的に
型変換して入れてやる事はままある。
ｎ

**デフォルトの名無しさん** · 2016/02/12(金) 20:46:32.04

>>51
物があるんだから具体的に何行目って言ってくれた方が分かりやすいとは思うけど、
見た目多分>>52であってる。
俺もそんなに詳しい訳じゃないし、APIの仕様も知らないけど。

ガーベッジコレクション(GC)をユーザが起動する方法はない。
参照が切れればいつか勝手に回収される。
ただ、見た目バカスカリークする可能性があるタイプのプログラムじゃないから、
多少リークしていたとしても問題ないと思うけどね。

リークが気になるなら、chromeならDeveloperTool、FFならabout:memoryで確認できる。
ちなみにそこにGCするボタンもある。

**デフォルトの名無しさん** · 2016/02/12(金) 23:30:42.28

>>53
// グローバル変数
var currentPos = new google.maps.LatLng({lat: 32.xxx, lng: 130.xxx});

//---------------------------------------------------------------------
// watchPositionSuccessCallback() 現在位置取得Success
//---------------------------------------------------------------------
function watchPositionSuccessCallback(pos) {
　currentPos = {lat: pos.coords.latitude, lng: pos.coords.longitude};　// あ、これがダメなのか？ここでnewしろと？
　var from = new google.maps.LatLng(currentPos); // ここで from に new しないで
　var to = google.maps.geometry.spherical.computeOffset(from, 350, heading); // 直に　currentPos　を使うとエラーが出ます

currentPos = {lat: a, lng: b};
って構文は
currentPos変数が保持してるLatLngオブジェクトのlatにaを代入、lngにbを代入する、
って思ってたんだけど違うのかなぁ？

ガベコレに関しては、ググると、
意図的にnullを代入すればメモリから消される、的なことを見たのだけどめんどくさいですよね。
上の例だと、
currentPos = null;
currentPos = new google.maps.LatLng({lat: 32, lng: 130});
最近のPCやスマフォはメモリ数GBとかあるしもう忘れることにしますｗ
きっとガーベージが増えたらGoogleChromeさんが勝手に掃除してくれますよね！

**デフォルトの名無しさん** · 2016/02/13(土) 00:01:10.41

>>54
currentPos={...}は、そのまんまcurrentPosに{...}を代入するだけで、
それぞれのプロパティに代入してくれるわけじゃないよ。
{...}自体が、new Object()だしね。
ガベコレが回収してくれるには参照を切ってやらなきゃならんのだから、null代入は必須。
意図的にnullを代入するとガベコレが回収する訳じゃないけど。
グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる。

**デフォルトの名無しさん** · 2016/02/13(土) 00:40:54.25

>>55
レスthxです。

プロパティに代入しちゃえ！って
currentPos.lat = pos.coords.latitude;
currentPos.lng = pos.coords.longitude;
やってみたけどできないのね。
https://developers.google.com/maps/documentation/javascript/reference?hl=ja#LatLng
LatLngってオブジェクトはコンスタラクタ以外では値の設定ができないのかな？
富豪過ぎるｗｗｗ

>{...}自体が、new Object()だしね。
>グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる
うーん、イマイチ理解できてないですけど、
currentPos = new Object({lat: a, lng: b});
というlatとlngを持ったLatLngではない別のObjectが生成された、ってことなのかな？

型が緩いのは便利だけどデバッグ時にはわかりにくすぎるという諸刃の剣ですね。。。
勉強になりました。ありがとうございます！

＃今回javascriptで組んでみて、CSSにも苦戦してるし、CSSとjavascript上のひも付けにも苦労してます（汗
＃あぁあああなんでぇええ　　って腹たつけど、意図的に動いた時にはやっぱり嬉しいですよね
＃プログラミングって楽しいですよね！

**デフォルトの名無しさん** · 2016/02/13(土) 01:31:30.78

>>54,56
既に指摘されているとおりだけど、

> currentPos = {lat: pos.coords.latitude, lng: pos.coords.longitude};
は
> currentPos = new Object({lat: a, lng: b});
> というlatとlngを持ったLatLngではない別のObjectが生成された、ってことなのかな？
これで理解はあってます。

> currentPos = {lat: a, lng: b};
> って構文は
> currentPos変数が保持してるLatLngオブジェクトのlatにaを代入、lngにbを代入する、
> って思ってたんだけど違うのかなぁ？
これは違う。分割代入の構文はまた別にある。
この構文だと新しく lat と lng を持ったオブジェクトが作られる。currentPosに入っていた物は捨てられる。
（正確に言うと参照が切れる。全てから参照が切れていればいつかGCされる）

型は無いようで有るというか、C的に言えば全部ただのオブジェクトでしかないのだけれど、
new するとコンストラクタが呼ばれ、結果的に初期値等が設定され、
さらにプロトタイプも設定される。
また、getter/setterやProxyとかで色々細かいことも出来てしまうので、
API で new しろと言われている以上 new しないと駄目。
(Webの場合はURLで引っ張っているので、対象が書き換えられたらいきなり更新される。
そのリンクだと多分バージョン固定だからこの点は大丈夫だと思うけど、
APIはAPI通り使わないと危険。）

> 最近のPCやスマフォはメモリ数GBとかあるしもう忘れることにしますｗ
GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど、
正直、今回のような場合の1個や2個はどうでもいいと思う。

> CSSとjavascript上のひも付けにも苦労してます（汗
基本的にclassを使えばいい。

**デフォルトの名無しさん** · 2016/02/13(土) 01:57:33.47

> ＃プログラミングって楽しいですよね！
正直、ブラウザ上でのプログラミングはかなり楽しいと思う。
GUIで具しか書かなくていいのでチャキチャキ感があっていい。
ただ、他の新しいGUIは知らないから、他にもいいのがあるかもしれないけど。

**デフォルトの名無しさん** · 2016/02/13(土) 03:17:29.54

>>58
色々教えてくださってありがとう御座います。

ブラウザ上のプログラミングも楽しいですけど、
PC8801mkII-SRからプログラミングを始めた私としては、
限られたCPU速度、メモリー、直接ハードを叩いてる感、も楽しかったんですよ
V-Sync割り込みで画像移動させるとスムーズに動くとかね。

そういうハードの限界まで頑張る、的な楽しみは今では無いでしょうけど
Google Chromeには便利なデバッガーあるし、
ネット上には情報がいっぱいあるし、
今の若い人たちはjavascriptから遊んでもいいと思いますね。
html5のcanvasでゲームも作れるし。
文法的にはCにもjavaにも似てるからどこにでも進めるでしょう。
職業：プログラマーという選択が良いか悪いかは別としてねｗ
趣味：プログラムなら一生楽しそうだけどなぁ。

**デフォルトの名無しさん** · 2016/02/13(土) 03:40:04.40

雑談ついでに。
私はプログラムはXyzzyで書いてます。
Windows用の軽いemacs互換エディタです。
http://www13.plala.or.jp/tarna/maps/ariakekai/icon/xyzzy.png
25年くらい前にX68000でTinyEmacsを使い始めてから、
もうemacsキーバインドじゃないと何も書きたくないです。
ゲーマーなんでWindowsを使ってますが、
Xkeymacsという、すべてのキーバインドをemacs風に変換するソフトが常駐してますｗ
今の環境はWindows７ですがWindows10にしたらXkeymacsが使えなさそうで怖いです。
最低Ctrl-H＝Backspaceにできないと死にます。

スレチ、失礼しました。

**デフォルトの名無しさん** · 2016/02/17(水) 19:47:14.33

今更ながらjs2-mode導入して色を付けてみたが、ちょっとイマイチだな。
キルリングの取り扱いが変わっていて慣れないし、
括弧閉じてもインデントが上がってくれない。
括弧の対応がハイライトされないのも謎だ。
まあもう少し使ってみるけど。

ただ、書いている最中に構文チェックするらしくて色が変わる。
これ自体は便利だと思うけど、どこまで使えるものなのかはまだよく分からない。

**デフォルトの名無しさん** · 2016/02/21(日) 09:27:40.55

>>57
>>GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど
それらでCGされる保証はない
エンジンは一般的な場合に最適化されてる
一般的でないことはしないのが基本

**デフォルトの名無しさん** · 2016/02/24(水) 01:04:57.69

すいません、キルリングの仕様変更はemacs23からのものらしく、
js2-modeは関係ありませんでした。

括弧の対応のハイライトはやはりおかしいままですが、
対応が間違っている場合はそもそも色が変わるので、
結果的にはあまり問題はないですね。

**デフォルトの名無しさん** · 2016/03/28(月) 23:29:32.90

nodeスレより
http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500

**デフォルトの名無しさん** · 2016/04/13(水) 23:34:15.51

textContentってquerySelectorで引っかけられないよね？とりあえず

Array.prototype.filter.call(src.getElementsByTagName('a'),function(dom){return dom.textContent==='XXX';})[0];

で取り出せるんだけど、もう少しましな方法って無いかね？（速度および見た目的に）
条件は、

1. <a>は10個くらいで、5～6番目が引っかかるので、そこでショートカットしたい。
2. 取り出すのは最初の1個でいい。

**デフォルトの名無しさん** · 2016/04/19(火) 11:57:14.77

速度も見た目も十分だよ
それを何度も実行する気なら状況によって要素や文字列をキャッシュすればいいし、
もっともっと短くしたいのならES2015を使えばいい

**デフォルトの名無しさん** · 2016/04/19(火) 21:54:42.16

テーブルに大量の行を挿入したい時とかって普通にやると応答止まるけどプロはどうやってんの？

**デフォルトの名無しさん** · 2016/04/20(水) 01:37:27.97

>>66
本当は、

querySelector('a[textContent="XXX"]')

と書きたいところだ。
ただこれは出来ないので、これまでは致し方なく別関数なりベタで書いていた。
しかし call に慣れてくると実は意外と使えることに気づく。
使い道の無かった filter も便利に使えるかと思ったのだが、
配列メソッドなのでショートカットが無いのが唯一残念なところだ。
（個人的には記述量は気にならない。）

**デフォルトの名無しさん** · 2016/04/20(水) 01:44:58.86

>>67
大量の行の挿入くらいじゃ止まらないし、
そもそも一画面分以上挿入する必要もないだろ。

具体的に何行挿入して、どれくらいカクついたらアウトなのよ？

**デフォルトの名無しさん** · 2016/04/20(水) 08:04:48.78

requestIdleCallbackで分割しながら挿入すれば良し

**デフォルトの名無しさん** · 2016/04/20(水) 09:52:44.31

vol.119で質問すれば良いのになぜこんな場所で質問してるのか
ここで詳しく回答する気は起きないので簡単にしかいわんけど
http://echo.2ch.net/test/read.cgi/tech/1457452716/

>>65
XPathを使えば良いと何度もいわれてる

>>67
1行ずつ何度も挿入してるんだろ
DFを使え

**デフォルトの名無しさん** · 2016/04/25(月) 00:30:16.00

ふと思ったんだが、forEach って何で currentValue が this になるのがデフォじゃないんだ？
グローバルじゃ意味無いよな？
引数で与えられるから動作としては問題なく、見た目だけの話だけど。

> forEach に thisObject パラメータが与えられると、callback の呼び出しのたびにそのオブジェクトが this として使用されます。thisObject が与えられないか null だと、callback に結び付けられたグローバルオブジェクトが代わりに使用されます。
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach

**デフォルトの名無しさん** · 2016/04/25(月) 04:01:16.41

thisに色んな意味を付けて何でもかんでも与えるなんてセンス無いから
現にアロー関数だったとき機能しないでしょ

**デフォルトの名無しさん** · 2016/04/25(月) 04:10:55.58

>>732
currentValue が thisになるのなんて、
DOMのイベントハンドラの中でthisが要素になるぐらいのもんだろ。
そもそもDOMはJavaScriptではない。
そもそもDOMがおかしいんだよ。

**デフォルトの名無しさん** · 2016/04/25(月) 08:11:57.07

>>73
> 現にアロー関数だったとき機能しないでしょ
あれはどっちかというと無駄な仕様変更だと思うが。
正確に言うと無駄な仕様を削除して新しく自動 .bind(this) に変更したわけだが、
その必要も無かった（と思う）

>>74
> そもそもDOMがおかしいんだよ
これはそう思う。というか、あれは this になることで無駄な手間が増えてる。
イベントハンドラを継承で与えるとき、(クラスでイベントハンドラを共有するとき）
いちいちインスタンスに bind しなくてはならないので面倒だ。
必要なら e.currentTarget でよかったのに自動 this だからこうなる。

ただここら辺も統一感がなくてイマイチではあるが、
現実的には何とかなる範囲ではあるので、（我慢できる範囲）
AltJSもイマイチ本家を殺しきれないといったところか。

**デフォルトの名無しさん** · 2016/04/25(月) 17:28:53.92

>>72
Array#forEachのコールバック関数にcurrentValueをthis値束縛する動作が自然ではなく、それによるメリットもないからだ
prototype上のメソッドでもないただのコールバック関数がなぜarrayでもグローバルオブジェクトでもなく、cirtentValueに束縛するのだ？
Function#bindでthis値を1に変更した場合、全ての要素値が1と扱う実装に利便性があるとは思えない
(arrayに束縛するならわからんでもないが)
forEachは第3引数でコールバック関数のthis値を指定できるが、これは異なるスコープからデータを渡すのに便利だ
(jQuery#eachにはこの機能はない)

イベントハンドラ関数のcutrentTargetへのthis値束縛もDOM3までは存在せず、DOM4で実装から逆輸入して規定されたものだ
addEventListenerには元々、handleEventでthis値を束縛する機能があり、thisをcurrentTargetとして扱うコードはhandleEventを利用した途端に修正を迫られる
event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
ちなみに、jQueryではhandleEventを利用出来ない

jQueryがthisを多用するのは仮引数を書く手間を減らす為だけに定められた歪なものだ
ECMAScriptでは関数呼び出しされるまでthis値が定まらない不定値だが、jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

**デフォルトの名無しさん** · 2016/04/25(月) 17:47:23.15

>>75
仕様「変更」ではない
アロー関数はより「ピュア」な新たな関数
newも出来ないし、thisやsuperも変数と同じように参照する
bindとは違う
統一感はある
DOMは関係ない、altJSでも同じこと
というかデファクトであってそれに依存するのは非推奨

**デフォルトの名無しさん** · 2016/04/25(月) 19:33:42.57

>>76
指摘の通りDOMをイメージしていて、
これまた指摘の通り全部thisでやろうとすること自体が糞だと理解した。

> (arrayに束縛するならわからんでもないが)
確かにこちらの方が自然だね。(とはいえthisにこだわるのが間違いだったが）

> event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
見た目相互運用できるようには見えないが、
(thisに揃えても同じコードを再利用できるとは思えない。もちろん揃えないよりはマシだが）
後付けでいろいろ奇妙になっているのは理解した。
> http://7cc.hatenadiary.jp/entry/eventlistener-handleevent

> this値に変更されて困る重要なデータを格納する
jQueryは知らないが、これはconstの代りに使うということか？
アクロバティック過ぎる。

>>77
> アロー関数はより「ピュア」な新たな関数
つまり機能限定版か。
そういう理解は出来なくもないが、導入するメリットは文字数以外に何もないだろ。
そりゃ意味無いって普通は言われるよ。
どうせ新規にするのなら、クロージャ無しとかまで踏み込んでもよかった。
(新規なら使い分けが必要/有効なところまで機能分離するべき）

**デフォルトの名無しさん** · 2016/04/25(月) 22:39:46.80

>>76
> jQueryがthisを多用するのは仮引数を書く手間を減らす為だけに定められた歪なものだ

違うよ。DOMの仕様に合わせただけ。

jQueryのイベントハンドラは、DOMのイベントハンドラと
互換性を考慮されて作られている。

例えば、この2つは同じように動く

$('#btn').on('click', function(event) {
　alert(this.id + event.currentTarget.id)
});

document.getElementById('btn').addEventListener('click', function(event) {
　alert(this.id + event.currentTarget.id)
});

どちらのイベントハンドラもthisは同じものを指しており、
またjQueryのeventオブジェクトはDOMのeventオブジェクトの仕様と
互換性を持たせて実装されている。

高い互換性ではないが、それでも程度はあるから移行が楽になる。

**デフォルトの名無しさん** · 2016/04/25(月) 22:47:27.73

>>76
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない

そんなことしません。

そう言う用途として使うのは、DOM要素のdatasetだよ。
このdatasetっていうのは比較的最近できたもので昔はなかった。

だけどjQueryは要素ごとの情報の格納場所の必要性を昔から認識していたため
datasetが作られるよりも前からdata()メソッドと言うのを持っていた。

そしてdata()メソッドがある理由の一つとして、
thisに直接値を格納するとブラウザのバグでメモリリークになる可能性があるから
「this（DOM要素）にデータを格納してはいけない。」と言っていたぐらいだ。

事実はあんたが思っているのと正反対だよ。

**デフォルトの名無しさん** · 2016/04/25(月) 22:49:10.70

これね。

https://api.jquery.com/data/

The .data() method allows us to attach data of any type to DOM elements in a way that is safe from circular references and therefore from memory leaks.

**デフォルトの名無しさん** · 2016/04/25(月) 23:32:07.55

>>76でhandleEventの話が出ているが、使った人ならわかると思うが、
handleEventはswitchでイベントを振り分ける必要があって使いづらい。

なぜこんな仕様があるかというと、そもそもDOMはJavaScript以外の言語も
考慮されて作られているという事実で説明できる。

つまり関数の引数、つまりaddEventListenerの引数に関数を渡せない言語が存在する。
具体的に言うとJava。Javaでは引数に関数を指定することができず、
オブジェクトは指定できる。

handleEventインターフェースを実装したオブジェクトを引数に取る関数と
考えるとhandleEventという仕様がなぜ存在するかがわかる。
これは便利だから追加された機能じゃない。Java等で必要だったっから
追加された仕様であって、JavaScriptでは関数をそのまま指定した方がいい。

76 · 2016/04/26(火) 00:48:49.99

>>78
> > event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
> 見た目相互運用できるようには見えないが、
document.all が標準化されたのと同じ理由だが、既存の資産(this で event.currentTarget を参照するコード)を生かす為だ
DOM3当時はデファクトスタンダードとして this 値が event.currentTarget を参照していたが、標準化されていなかったので確実に動作する保証がなかった
DOM4で標準化された事で既存のコードが確実に動作する事が保証された
単純に相互運用性を考えるなら event.currentTarget を使ったほうが良いのはいうまでもないが、
IE6の影響でXHTMLへの移行が進まなかった教訓を得てバッドノウハウでも積極的に取り入れて互換性を確保する方向にシフトした

> > this値に変更されて困る重要なデータを格納する
> jQueryは知らないが、これはconstの代りに使うということか？
これは言葉足らずだった、すまん
先述の jQuery.each と同じだ

// bad
jQuery.each([1, 2, 3], function (i, value) {
console.log(this); // Strict Mode なら Number型、sloppy mode なら Object 型 (Function#bind で変更される可変値)
});

// good
jQuery.each([1, 2, 3], function (i, value) {
console.log(value); // 常に Number 型 (Function#bind で変更されない固定値)
});

繰り返し処理をする上で要素の値は固定値でなければならないので this 値を指定すべきではない

**デフォルトの名無しさん** · 2016/04/26(火) 00:50:01.95

>>80
> jQueryは要素ごとの情報の格納場所の必要性を昔から認識していた
これは俺もすごく思うが、
実際のところはリークと速度低下が怖くてJavaScript側で持っている。
さすが実用ライブラリだけあって痒い所には手が届いているというところか。

>>82
> handleEventはswitchでイベントを振り分ける必要があって使いづらい。
これは何故？俺は使ったことは無いが、見る限りそういう感じではない。
イベントハンドラは基本的に直リンクというか、振り分け済みの関数を与えるのが基本で、
thisが効くオブジェクトを与えられるのなら、子クラスを与えればいいだけ。
当たり前だがオブジェクト指向の基本どおりだ。
また、最初からイベントハンドラ内で振り分けする気であれば、
ルートNodeにイベントつけてe.targetのclassで判定するのが自然だ。
何か別の条件ではまっただけの気がするが。

とはいえ、DOMの仕様がJavaScriptから見て中途半端なのはJavaとの相乗りが原因だとは理解した。

76 · 2016/04/26(火) 00:51:40.14

>>83の続き

// bad
function fn1 (event) {
this.classList.add('hoge');
}

// good
function fn2 (event) {
event.currentTarget.classList.add('hoge');
}

element.addEventListener('click', fn1); // OK
element.addEventListener('click', fn2); // OK
element.addEventListener('click', {handleEvent: fn1}); // NG
element.addEventListener('click', {handleEvent: fn2}); // OK

handleEventを拡張した場合、this値を指定したコードは動作しなくなる
ようするに、this は可変値なので固定値をとりたい場合に使用するべきではないという事だ

---
this が可変値である事を上手く利用した例に Array.prototype.forEach がある

Array.prototype.forEach.call(document.querySelectorAll('.test'), function (element) {
element.classList.add('foo');
});

これが動作するのは Array.prototype.forEach が this 値が配列でなくとも動作するように設計されているからだ
this 値は変動するから Function#call や Function#bind が生きる
だからこそ、this 値が変動する事に価値を見出せる設計にする必要がある

76 · 2016/04/26(火) 01:08:23.70

>>80
jQuery でも event.currentTarget で書くことは出来るが、ドキュメントのサンプルコードを読む限りでは作者が this を推奨しているように読める
「許さない」は言いすぎだったかもしれないが、this を推奨するという事は this 値が変更される事を考慮していないのではないか
this 値は実行コンテキストに入る時点で決まる不定値であり、this === event.currentTarget になる保証はない
https://api.jquery.com/on/

余談だが、jQuery#each と Array#forEach でコールバック関数の引数順序が違うのは this 束縛がある影響だと考えている
jQuery では this で各要素ノードを参照できるので第1引数に element を持っていくと index を参照する為には第2引数まで書かなくてはならない
forEach の設計としては直感的ではないが、ショートコーディングの為に index を第1引数に持ってくる歪な修正を加えたようにしか見えない
https://api.jquery.com/each/

jQuery('.hoge').each(function (i, element) { console.log(this, i, element); });

76 · 2016/04/26(火) 01:50:16.54

>>80
> 事実はあんたが思っているのと正反対だよ。
jQuery#data は優れた機能(ただし、data独自属性の拡張はいただけない)だし、jQuery() のセレクタエンジンは素晴らしいものだった
JSON, querySelector 等、優れたライブラリ/先行実装が標準仕様に取り込まれるのはよくある事だ
jQuery の全てを否定したいわけではなく、「jQuery の this の使い方が好ましくない」と主張している

> そう言う用途として使うのは、DOM要素のdatasetだよ。
dataset は String 型しか格納できない為、jQuery#data の代替にはならない
jQuery#data の代替として期待されたのは DOMUserData だが、この API は残念ながら廃止された
https://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#DOMUserData
今では機能的に逆だが、WeakMap が代替となりうるだろう
http://www.ecma-international.org/ecma-262/6.0/#sec-weakmap-iterable

**デフォルトの名無しさん** · 2016/04/26(火) 11:16:02.05

つうか結局何が言いたいの？
thisはpythonのselfみたいに一定の規則はあるが
あくまで０番目の引数みたいなもんで何に使おうが勝手だし
そういうのを利用するならきちんと把握しないといけない
その程度のことに良いとか悪いとかはない
使いたいならただ受け入れればいいだけ

なんかよく分からんけど気持ち悪いみたいな
結局愚痴をダラダラと言いたいだけならもうここら辺でやめとけ

**デフォルトの名無しさん** · 2016/04/26(火) 17:56:08.45

C#みたいにobj.Methodでバインドしてくれれば楽で綺麗に書けるのにね
いちいちbindって書くの面倒

**デフォルトの名無しさん** · 2016/04/26(火) 19:15:29.79

>>88
ここまで説明されて愚痴にしか読めないのなら口を出さなければ良いと思うけど

**デフォルトの名無しさん** · 2016/04/26(火) 19:52:24.85

>>89
引数としてメソッドを渡す際は今だと
obj.method.bind(obj)
よりもアロー関数を使って
()=>obj.method()
の方が良いかもしれない

あとバインド基本にするのは結構簡単
クラスのプロトタイプにそういうプロキシを挟めばいい
アノテーションとか使えるようになればなお綺麗に書けるね
まあバインドシンタックスobj::methodとかもあるんだけどね

そういうのを使えるトランスパイラ使うってのも悪くないと思う

**デフォルトの名無しさん** · 2016/04/26(火) 23:52:32.19

>>83
前半、言っていることは分かるんだが、現実的には、
this がDOMであるコードと自前のオブジェクトを this 参照するコードを
同一のコードで処理（相互運用）するためには、
自前のオブジェクトをDOMモドキにする必要があって、
（DOMと同じプロパティ等でアクセスできるように形を揃える）
これだと余計に苦労する。
だから結局、既に書かれたコードを流用することは難しく、
書き直すかラップしてしまうほうが簡単だ。
多分現実的には相互運用をしている奴は少ないのではないかと思う。
もちろんthisで共通アクセスできないとその可能性すらないからそれよりはマシだが、
現実的にはこの仕様はあっても使えない。

**デフォルトの名無しさん** · 2016/04/26(火) 23:53:03.95

>>82の話の通りなら、handleEventはJava用であって、JavaScript用ではないことになる。
実際、>>85ではメリットが無いだろ。
JavaScriptでわざわざ使うのならメリットがある以下の記述になる。

var hit_list = new Set();
var EventHalndler = function(){
this.status = 'waiting';
}
EventHandler.prototype = {
handleEvent: function (e) {
e.currentTarget.classList.add('hoge'); // class で管理
this.status = 'hit'; // 個別オブジェクトで管理
hit_list.add(e.currentTarget); // Set で管理
}
};
var ehandler = new EventHander();
element.addEventListener('click', ehandler);

DOM側で管理するならclass、JavaScript側で一括管理でよければSetでいい。
どうしても個別のオブジェクトに格納したければ「thisを生かして」使うことになる。
当たり判定のグルーピングを細かく変更したいときはこのやり方が適するけど、
用途はあまり無いと思う。

**デフォルトの名無しさん** · 2016/04/26(火) 23:54:04.46

だから「相互運用」を考えるのなら、
e.currentTargetとthisの両方を異なる意味で用いている上記のようなケースをどうするかであって、
多分これはどうにもならんだろ。
手っ取り早いのはラップ関数内でthis値をMapなりから引っ張ってきてしまうことだが、
要するに書き換えが必要なので仕様をわざわざ合わせた意味がない。
何らかのために仕様をあわせたというのなら、
そのおかげで書き換えなくても済みました！がないと意味が無い。

DOM側からすると妥協だということだが、放置でもよかった気はする。（仕様として追認の必要なし）
なお、thisかe.currentTargetの片方しか使ってないコードは自動でも書き換えできる範囲だと思う。

しかしそうなると問題の出所はブラウザの実装で、
何故e.currentTargetに統一せずにthisを渡すことにしたかだな。
正直、あれ、thisで渡されても全くメリットないよな？

> DOM4で標準化された事で既存のコードが確実に動作する事が保証された
これは多分、気にする人にとっては重要なのだろうけど、
Webサイトなんて10年後の動作を保証されたところで意味が無いし、
「当面(数年）確実に動く」であれば大半の人にとって問題ない。
それが実装主体で推移している原因にもなっていると思う。

**デフォルトの名無しさん** · 2016/04/26(火) 23:55:02.00

>>82
とここまで書いて気づいたが、switch は e.target ではなく e.type か。
確かにこれでは使いにくいな。JavaScriptなら以下で逃げられるが、
これが出来ないからオブジェクトで与えているのだと思われ、Javaでは壮絶な糞コードになりそうだな。

EventHandler.prototype = {
handleEvent: function (e) {
this[e.type].call(this,e);
},
click: function(e){},
mouseover: function(e){},
mouseout: function(e){},
};

**デフォルトの名無しさん** · 2016/04/26(火) 23:55:42.51

>>86
いやそのjQuery.eachのthisは意味があるぞ。
それならthisで書かれたイベントハンドラをeachで回せる。（DOMのイベント寄り）
ただe.currentTargetで書くべきだというのと、
そもそも他に代替手段がありまくるので、割とどうでもいいが。
thisを固定したことによるデメリットの方が上回るかもしれない。

ただまあ、そちらの主張どおり、
thisに対しては緩く考える（○○が来ると仮定しない）方が何かと便利なのは事実だろう。

**デフォルトの名無しさん** · 2016/04/27(水) 00:28:53.55

「thisは基本レシーバ」
それ以上でも以下でもない

**デフォルトの名無しさん** · 2016/05/01(日) 14:45:40.12

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
「

**デフォルトの名無しさん** · 2016/05/03(火) 12:04:12.37

もうWebRTC利用したJS製のそういうフレームワーク何個も作られてるよ

**デフォルトの名無しさん** · 2016/05/03(火) 18:27:13.57

WebRTCって要するにP2Pチャットサーバ用だよな。
元々それ用だけどそれ以外に用途が無い。
もちろん発展させればWinnyやskypeみたいな事は出来るけど、それなら最初からそっちでいいし。

俺も最初知ったときは「ウッヒョー」だったけど、冷静に考えたら落ち着いた。
現実的には大半の事案は鯖立すればいいだけだからね。
技術的には面白いとは思うけど。

**デフォルトの名無しさん** · 2016/05/04(水) 19:58:18.58

ちいと勘違いしてるが、WebRTCに鯖とのやり取りもといマッチングの仕組みは含まれていない。
WebRTCでそれをするのはちょっとハックっぽくなるが、
特にORTCなら鯖レスの固定相手P2Pも素直にできる。

現在は
・ビデオ/ボイスチャット
・MMOゲーム
・一方向型のファイル共有
によく使われてる

**デフォルトの名無しさん** · 2016/05/04(水) 23:45:02.80

> MMOゲーム
これにはいいかもな。

それ以外は正直、「ブラウザでできる」以上の意味は無いよね。
最初からP2Pする気ならP2Pアプリを使った方がいろいろいいし。
一方向型のファイル共有ってそれただの鯖じゃん。

**デフォルトの名無しさん** · 2016/05/05(木) 04:30:39.98

ブラウザでできるからこそ特大の意味があるんだよ
今著名なWebサービスはアプリも出してることが多いけど、
じゃあ皆がそっちの方を使ってWeb版はいっさい要らなくなるかというとそうではない
一時期そういう流れも起きたがやはり無理だったということで、今は流れが戻っている（Flipkartが良い例）
わざわざアプリをインストールして管理しないといけない手間が要らないのはとてつもない利点だよ

そして、ファイル共有に関しては鯖レスで実現できるところがメリット
鯖を挟むと帯域を本来の２倍取り、さらに負荷が鯖に集中してしまう
宛先の絞られているファイル等はP2Pで送る形のほうが良い

**デフォルトの名無しさん** · 2016/05/05(木) 09:25:46.88

ブラウザのBBOM化はもう勘弁して

**デフォルトの名無しさん** · 2016/05/09(月) 15:41:03.36

なんで？

**デフォルトの名無しさん** · 2016/05/09(月) 22:54:55.21

BOMのことだよな？
個人的にはDOMやBOMでAPIアクセスできるのはお手軽でいいと思うぞ。

**デフォルトの名無しさん** · 2016/05/09(月) 23:34:30.27

もはや種類多すぎる上に増加スピードが速すぎて把握するのがしんどいわ
でも無ければ無いで何も作れないしな

**デフォルトの名無しさん** · 2016/05/10(火) 10:34:10.82

スピードが早いというが、一年くらい前から高レベル系のAPIが熟成期に入って停滞してると思う
また来年くらいから今度は低レベル系のAPIが動き始めるんじゃないかな

**デフォルトの名無しさん** · 2016/05/10(火) 23:06:42.46

> 低レベル系のAPI
上の話ともリンクするが、ブラウザはお手軽さが最も重要なのであって、
ゴリゴリ書いて性能を出すのには不向きだし、流行らないと思うぞ。
結局のところ、専用ネイティブアプリには実行効率では勝てないのだから、必要なら開発される。
そこまでの必要/需要が無ければブラウザアプリのままでいけることになる。

ただ一つ思うのは、CPUとI/Oを分離し、非同期で書くことを強制するのは、実はかなり効いている。
体感、思っているよりだいぶ速いんだよね。
他言語だと普通に同期で書くし、描画でもそのまま記述する。（分離して書く習慣が無い）
これら遅い部分を明示的に分離し記述することが半強制されている結果、
結果的にCPU稼働率の高い「割と速い」コードが出来上がることとなっている。

だからちゃんと書いたJavaScriptは十分速いし、
それ以上の速度を要求するのならC/C++で書き直すしかない。(V8がC比5倍程度と十分速い為）
どんなJavaScriptでも最後にトランスパイルすれば速くなるというのなら、それはJIT側に含まれるべきだし、
何らかの記述制限をつけて「ちょっと速いJavaScript」を目指すものは、多分需要が無い。
（本来そこにはC比3倍程度というJavaアプレットがいたはずだが、完全に死んでるし）