JavaScript情報交換所(プログラミング既習者専用）
プログラミング既習者専用です。初心者の方はご遠慮下さい。
玄人の方、歓迎致します。
【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ52【php,py,pl,rb】 [転載禁止](c)2ch.sc
http://peace.2ch.sc/test/read.cgi/tech/1443578172/
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference
ここで言う初心者とは、3,000行のプログラムを動かすのにも苦労する人達のことです。
なお、JavaScriptの習熟度は問いません。
言語を問わず、3,000行程度なら楽勝であれば問題ありません。
(2) 初心者だと思える投稿は無視してください。初心者用スレは他に沢山あります。
(3) 質問スレではありません。特に初心者からの質問はガン無視でお願いします。
(4) 長文が読めない低脳はお引き取り下さい。
【リンク集】
https://developer.mozilla.org/ja/docs/Web
https://msdn.microsoft.com/ja-jp/library/yek4tbz0.aspx (JavaScript)
http://hakuhin.jp/js.html (逆引き）
http://stackoverflow.com/
他仕様書等のリンクは質問スレのテンプレを参照してください。かなり整備されています。
プログラミング既習者であれば、MDNとMSDNでほとんど事足ります。
ブログ等は間違いが多すぎるので、MDNのサンプルコードから出発することを薦めます。
逆引きなら上記hakuhin.jp、困った場合はstackoverflowが秀逸です。
【初心者用スレ】
JavaScript の質問用スレッド vol.118 (ム板質問スレ)
http://peace.2ch.sc/test/read.cgi/tech/1429634108/
ECMAScript デス 5 (ム板仕様スレ)
http://peace.2ch.sc/test/read.cgi/tech/1449027632/
【超初心者用スレ】
JavaScript の質問用スレッド vol.127 (Web制作板質問スレ/頻繁に分裂中)
http://peace.2ch.sc/test/read.cgi/hp/1448293871/
テンプレは>>1と>>4
Web制作板はIDが出ないのでアフィカス/teratailerが暴れている感がある。
「1〜10まで足す」みたいな質問にも回答が付くという奇妙さだ。
また、ライブラリ厨の意味無い布教活動も嫌がられている。
個人的には低脳アフィカスが一番の癌だと思うが、
奴らは印象操作が目的なので反論されても喚きちらすだけ。
もう超初心者スレとして分離するしかない。
回答する奴も初心者なのでデタラメだらけだが、あいつらにはそれでも問題ない。
明らかに間違っている事を正しいと言い張る馬鹿共を矯正する方法は2chにはない。
ム板の質問スレはIDが出るので、逆に言えばIDが出て困る奴はいない。
ほとんど流れていないが、質問すればWeb制作板と同レベル以上の回答は付く。
まともな回答を期待するのならこちらに投稿した方がいい。ただし回答が付くまで時間がかかる。
Web制作板の方はIDが出たら困る奴が「流れているスレ」として見せるために無理矢理流している感がある。
このため、上記のように、ただ単に無視すべき投稿にもレスが付く、どうしようもないスレになっている。
また、どうでもいい一般論を投げかけ、無理矢理流そうとしているものも散見される。
やりたい放題やられているわけだが、しかしその先には何もないように思えてならない。
何がやりたいのかはかなり疑問だ。ただ、止める方法もないので、分離するしかない。
仕様について厳密に詳細を確認したければECMAScriptスレがいい。
正直、他も含めてJavaScriptスレ住民の仕様に対するこだわりは異様だと思うが、
逆に言えば、厳密に議論したければ相手はそこにいる。
ただしそいつらは仕様にはすごく詳しいが、コードは記述していないらしく、
何が本当に問題なのかを実感できていない。
だから地に足のついていない議論になってしまう。
とはいえ、詳しいことは事実だ。だから仕様について正確を期すのならそこがいい。
現時点でまともな奴がほぼいないので、新しく訪れてくれる人を待つことになる。
気長な話になるが、やらないことには始まらないので、とにかく始めることにする。
3,000行についてだが、OAOOはもちろん徹底しているとして、
1,000行なら勢いで書いてしまえる規模だ。
ところが3,000行となると、内部構成をある程度マトモに設計していないと破綻し始める。
逆に言えば、内部設計を正しく行い、かつ実装できる人の目安として3,000行を楽々、とした。
11/28に立てたスレ（同スレタイ）
http://peace.2ch.sc/test/read.cgi/tech/1448714123/
が何故か1週間で落ちたので、もう一度立て直した。
2ヶ月以上書き込みがないスレもこの板にはあるので、書き込みが無くて落ちたわけではなさそうだ。
削除依頼も確認してみたが、該当はなかった。
質問スレがvol118, vol124と完全に被っているのに放置されているため、重複削除でもない。
原因が不明のため、とりあえず再び立てて様子見することにした。
一応7日ほどは持っていた（はず）なので、4-5日程度毎に俺が話したい案件を上記前スレ
http://peace.2ch.sc/test/read.cgi/tech/1448714123/4-7
からコピペしてきて落とし、これでしばらく持たせる。
もちろんそれ以前に話題があれば勝手に開始してくれて構わないし、
俺の案件についてレスを付けてくれれば応じる。
このスレの狙いは、まずは人を集めることだ。だから半年以上持たせる必要がある。
あの質問スレの状況だと、まともな上級者はウザがって寄りつかない。
上級者を集めたいのなら、彼等にとって読む価値のあるスレを用意して待たなければならない。
これには時間がかかる。機能するには半年以上かかるだろう。
しかし、やらないことには始まらないので、とにかく始める。
出来るだけ落ちないように努めるが、いかんせん基準が分からないのでまた落ちるかもしれない。
その場合は再び立て直すが、それにしても落ちまくるのは問題なので、
基準を知っている人がいたら教えて欲しい。
10レス未満だと落ちるよ
ありがとう。了解した。
とはいえ予定は7の通り。
EMCAスレが落ちているのを確認した。
10スレ未満は丁度1週間で落ちるようだ。
それはそうと、現実問題として上級者がJavaScriptにはいない（いにくい）のかもと思うようになった。
元々は単なるヘルパースクリプトで、質問スレ見ても分かるとおり、単発の修正とかに使われていた。(はず）
今なら「PHPでやれ」と回答すべき案件等と言えば分かりやすいか。
Ajax以降は必要となれば大型化するが、クライアント側に大型データ構造を持つ使い方は自然ではない。
MMORPG等をWebGLで実現するにしても、クライアント側は描画に徹してデータはサーバ側に送るのが普通だ。
だから内部構造にこだわるべき中級者以上が育たない（必要ない）環境なのかもしれない。
あるチームでサーバクライアント型アプリ（ゲームでもチャットでもいいが）を作るのなら、
サーバ側に実力者を振り分けなくてはならないのは自明だ。
とはいえ、出てくるかどうか待ってみることにする。
ググれば分かるとおり、奴らはQiitaが好きみたいだが、俺は匿名の方がいいと思っているので。
とはいえ、匿名掲示板はどうしても雑音が多すぎる。
彼等がQiitaのほうを好むのなら、いくら待っても空振りで終わる。
それでも俺は試してみるが、盛大に空振りするかもしれないのでそのつもりで頼む。
https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript
言語仕様を愛する人と、WebAPI技術を愛する人と、フレームワークを愛する人は違うだろうし。
ああ、あれは明らかに違う連中だ。少なくとも俺と同じ側ではない。
プログラミングなんて本来は手段、従ってプログラミング言語は包丁であって、
もちろん包丁職人やコレクターもいていいが、道具として使う料理人が一番多いのが普通。
しかし彼等は異様に細部にこだわっている。彼等は何者だと思う？
そもそも仕様仕様とうるさいのだが、仕様の細部なんて使わないのが普通だと思うのだが。
Q. String が期待される関数 function func(str) に対して Array が与えられた場合はどうするべきですか？
A1. 当然暗記している型違い時の変換規則を活用し、適切に対処します。
A2. それはただのバグです。
型付き言語だとそもそもA1はコンパイルが通らない。
俺は型付き言語出身だから、当然A2で組んでいる。使う予定のない変換規則なんてどうでもいい。
ところが彼等はこれじゃ駄目だと喚く。
でも具体的にどう活用すればメリットがあるのかは示せない。
何なんだよいったい、と思う。
ところで連中は立て直さないのかな？
それはダックタイピング系のことをちょっと大げさに捉えすぎて無いかい？
それと引数の型についての選択肢としては
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派は、来て欲しい型でなければエラーとするのが最も安全。
というような主張だろうが、君はどんな主張で、どんな主張に納得してないの？
後者でいうと、Stringが期待される場面でArrayが来た場合なんてどうしようも無いだろうが、
Arrayを期待する場面なら他のArrayLikeなオブジェクトもArrayとして見てやるべきじゃないかという論になる。
そこで、また派閥が分かれるだろう。
何もしないまたはエラーとする（Array.isArray）（Arrayだけしか面倒を見ないから）、イテラブルだけ面倒見る（[...arg]）か、
多くのArrayLikeを面倒見る（Array.from(arg)）か、何もしないまたはエラーとする（例えArrayに変換できなくともArrayのメソッドを持っていればよい）
また、配列の使い道によっては@@isConcatSpreadableを考慮するかどうかも問題になってくるだろう。
Object.prototype.toString.call(arg) == '[object Array]'
とArray.isArrayの違いとどちらが適切かを語るレベルまでいけば一人前か。
まあ彼らは意味に敏感なんだろう。
配列を期待するといっても、配列はいろいろあるし、期待の仕方もいろいろある。
なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
以下4投は転載。
気になる物があれば勝手にレスを付けてくれ。
もちろん他の誰かが勝手に始めてくれても構わない。
俺も気になれば勝手に参加するし、どうでもよければ無視する。
使い方は基本的に他のスレと同じ、ただし初心者お断り、だ。
http://peace.2ch.sc/test/read.cgi/hp/1444186237/550
http://peace.2ch.sc/test/read.cgi/hp/1444186237/562
JavaScriptに於けるコーディングストラテジーだが、単純には以下2つのどちらかだと思われる。
α. 安全重視、全箇所で型/値チェック。
β. 簡素化重視、最初に型チェック、以降は「型」までは確定、値については保証無し。
αは関数単位で抜き差しが可能。その点機能の追加/削除は楽だ。
各関数は型判定等を持つため複雑になるが、安全領域を管理する必要がない。
βは期待される型以外では何も考える必要がないため、その分関数の仕様が小さくなり、
デバッグが楽でバグも出にくく動作も速くなる。ただし、型チェックを既に通っているかを管理する必要がある。
ネットワークに於けるファイヤウォール内/外の管理のようなものだ。
基本的に関数毎の抜き差しはできない。型チェック部分＋動作部分のセットでやらないと駄目だ。
だから関数単位での粗結合化はできない。
俺はβでやっている。
そして現実的にはβしかないように思えるのだが、どうか？
可能であれば直接本職の方々の意見が聞きたいが、
JavaScriptはソース見放題だから、企業のサイトのソース（=本職製）からの類推でもいい。
ダックタイピングを生かすのなら多分αじゃないと駄目なのだが、
俺は型システムに慣れているというのもあって、今のところダックタイピングの利点を感じられない。
αだと各関数で様々な型を処理しなければならず、これがバグの元になるので、
最初からStringならStringと決めうちで各関数を用意、Stringしか入力されないように上位階層で対応している。
静的クラスでは出来なくて動的プロトタイプでは出来ることを使って、何かできないか。
今思いつく中では、以下がある。
A. 動的プロトタイピング(__proto__の頻繁な変更）
B. インスタンスツリー
C. 親への透過的アクセス（親に動的に追加されたプロパティに対する透過的アクセス）
Aは変更自体はやっているが、頻繁に変更する需要がないのでそれ以上試していない。
Bは現在試しており、見にくくなる以外の弊害はない。見にくさについてはデバッグ用環境を整えて対応した。
メリットはフィールド共有によるフットプリント削減だが、
しかしこれはあらかじめ共有すると分かっていれば静的クラスでも出来る。
デタラメに共有したりしなかったりする場合も、
共有する派生クラスと共有しない派生クラスを用意すれば、静的な場合は対応可能になる。
従ってどうしてもというのならやはり動的なものに限られてしまうのだが、これは需要がない。
Cは試したいところだが需要がない。
従って、仕様としては出来るが、実際の需要がなく、活用できていない。
他の活用案もあれば是非。
共通基底クラスを持つ場合、当然ポリモーフィズムできるとして、
ダックタイピングの場合は、共通基底クラスを持たなくても、共通の名前のメソッドがあればポリモーフィズムできる。
だからといっても、活用案がないので、事例があれば是非。
>>16
こちらは基本A1で組んでいる。初段はA2もあり得る。
理由は>>21のとおり、入力段で型を確定させる方が楽だと判断しているから。
JavaScriptの場合、型が確定しないのはDOMか鯖からの入力に限られる。
だから最初の段で型を確定させ、以降は型確定で組んでいる。
この場合、型確定エリアと型不確定エリアが明確に分離されるので、型確定を忘れるとおもむろにバグる。
しかしこれは前述のように限られており、見落としたりする心配はほぼ無い。
型を不確定のまま伝搬させるのは余計に難しい。だから通常あり得ない。
となるとA2/A3が必要なのは「どこから呼ばれるか分からない」という関数だけになる。
（型不確定エリアからの直接呼び出しがあり得る）
これについてはプログラムを見てそういうことがないように確認すればいいという事にしている。
というわけなのだが、どうかね？
A2/A3は関数の機能としてはA1のスーパーセットになる。型が予想外の時の分だけ仕様が大きい。
だからA1で組んでしまうのが楽だ。問題は見落としがある可能性が残る点。ただし、これは見やすい。
A2/A3の場合は見落としは考える必要はないが、
個々の関数が全ての型について設計通り動くことが求められるので、
テスト項目が多くなり、またバグを誘発しやすいと見ている。
ちなみに、「何が来るか分からない時でも正常動作」というのは、考えていない。
というか、その時はバグっていいという判断だ。
・入力が明確に間違っている場合、再入力を求める。誤入力状態での表示はどうでもいい。
・Ajax結果が不正の場合、リロードする必要がある。このときも表示はどうでもいい。
所詮はヘルパースクリプトだから、この辺で留めている。
それはダックタイピングだと思うが、正直俺はその点に関しては気にならない。
期待通り動けば何でもいい。
気になる人は例えばtoString()の解釈について、
・ダックタイピングだ。toString()があるから使えるだけ。
・各型についてtoStringというインタフェースが実装されているのだ。
・toString()はテンプレート関数で、各型についてオーバーライドされているのだ。
と考えることが出来るかもしれないが、俺はどれでもいいと思っている。
JavaScriptはthisを関数側に持たせているため、callを使って他型のprototype等を間借りすることが出来る。
これは便利ではあるが、しかし真面目にインタフェース等で実装すれば済むことが大半だ。
だからこの方式もthisがいちいちはがれてbindしなければならない方が面倒だ。
classシステムのようにインスタンス側にthisを持たせる方が理に適っているように思う。
つまり、callで突っ込むのは勝手だが、ちゃんと動くかは「確認しろよ」ということだ。
その手の動作範囲を広げていくのは、YAGNIとかKISSとか言われるらしいが、大体無駄に終わる。
だからArray.fromの実装側は自分が使う最小限に留めて良く、間借り側が正常動作を保証しろと考える。
これはおそらくJavaScriptの思想とも合致している。
ArrayのメソッドはgetElementsByTagName等で返されるCollectionに対しても大体動作するが、
動作の保証はしていない。
つまり、間借り側(Collectionでcallする側）が正常動作を保証（確認）する必要がある。
クラスシステムの場合、実装してあれば確実に動作するし、実装していなければ動作はしない。（間借りも出来ない）
JavaScriptの場合は、使えそうなら使ってねといういかにも曖昧な感じで、それでいいのか？という疑問はあるが、
上記のように、「バグってたらリロードでおk」ならこの方が色々楽なのは事実だ。
結局の所、出自が（というよりも今も大半の用途でも）チョロスクリプトなので、それ向けに仕様がチューニングされている。
これで大規模なプログラムを組むのがそもそも無理がある、ということなのだとは思う。
チョロスクリプトとして使う分には、なかなか面白い仕様だと思う。
それは同じだと思うが、違うのか？
=== なら以下にポリフィルとしてそのまま記載されている。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/isArray
== の場合もその場合は危険性がないように思える。
ただし、これについては俺は真面目にやってないので自信はない。
ただ、そもそも「文字列との比較は === 」というのが lint で引っかかるので、常にそうすればいいだけだ。
> なまじいろいろ知ってるだけに細部に拘りたくなるのだろう。
これはあると思う。
あれだけ仕様が小さくて頭の中に入りきるサイズだから、というのはかなりあると思う。
C#やJavaなら調べながらのコーディングになるので、気にしてられない。
問題はArrayが少し変わったオブジェクト程度であること
そしてArrayのメソッドは、ArrayLike（この場合lengthを持つもの）について保証していて最初からそのように作られている
JSにおいて配列の最も基本的な定義はlengthプロパティに要素の長さを記録しているもの程度のことでしかない
当然DOMの配列でも動くし、型付配列でも動く
それなのにわざわざArrayだけでしか動かなくする必要があるのか？
ここがミソで、わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
Array.isArrayは型付配列すらtrueを返さない
isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ
配列を扱うとする関数でArrayだけに絞るのはJSにおいて必ずしも十分ではないということだ
その関数を作る目的と使われるシチュエーションを考慮しないといけない
>>27
@@toStringTagをお忘れかな？
===の件もそうだな
どうして必要もない制限をわざわざするのか？と思ってしまう
というのは半分ウソで、実際は他の演算子と文字数が違うものを基本で使うのは気持ちが悪いから==を基本で使う
経験上==を基本で使ったからといってバグになるようなことはない
型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
> そしてArrayのメソッドは、ArrayLike（この場合lengthを持つもの）について保証していて
> isArrayは配列がどうかのチェックではなく、Arrayかどうかのチェックだ
これは「isArray は Array.prototype の動作を保証するかどうかを返す」と考えていいのか？
これならまあ使える仕様だ。
ちなみに確認したが、DOMのCollectionについては isArray は false になる。
実際の所、このCollectionは無理矢理Array的アクセスが出来るように見せかけただけのものであり、
書き換え不能にしてあるから、例えば Array.prototype.splice.call(DOMのCollection,1,1) は（エラーを返さないが）動作しない。
だから辻褄は合っている。
まあ正直、「動作しないのならエラー返せよ」と思うが。以前はまった。
> @@toStringTagをお忘れかな？
ああこれは知らなかったからだね。
これも自然な仕様だが、だとするとMDNもちょっと書き換えたほうがいい気はするが。
> 型変換のバグは予想外に同値判定で通ってしまうことよりも、予想外に通らない事のほうが圧倒的に多いのだから
まあ実際はそうなるはず、というかそれを目指して型変換規則が作られているはずなので。
実際のコードを見ると、==派と===派は半々という感じか。
一応googleのコーディング規約には === を使えと明記されていたはずだが、今見ると無い。
削除されたか、或いは俺の勘違いかだが、しかし日付を入れてないからどっちか分からない。
https://google.github.io/styleguide/javascriptguide.xml
この手のドキュメントのリリース日が辿れないってマジで馬鹿なのかあいつら。
というかこの辺で色々文化が違って無駄にストレスが溜まる。
俺は見た目はどうでもいい派なので、文字数の違いとかは気にならない。
俺が組んだところは基本的に === でも動くようにしてあるので、全部書き換えてもほぼ問題ないはず。
実際は歴史的経緯で混在しまくり、今更書き換えてデグレードするのは避けたいので、放置している。
ただJavaScriptの本来の設計は == なのだと思う。
（基本 == で、真に必要がある場合は === で)
というか、おそらくそちらの方がプログラミングとしては正道だ。
JavaScriptの仕様は、「チャキチャキ作ってサクッとリリース」向けであり、「バグがないプログラミング」向けではない。
とはいえ、Webにはこれが正しいのも事実。
マイナーバグに対する作り込みでリリースが遅れるくらいなら、
バグがあってもクリティカルでないのならリリースした方がWebにはいい。
相手は「今欲しい機能」を求めているのだから。
逆に「バグのないプログラム」を目指すのなら、基本===ベースで行った方がいい。
相手は「将来欲しい機能」を求めていて、そこにバグがあっても困るという人だから。
ここら辺は置かれた状況の違いで文化の差異が発生していると考えている。
> わざわざArray以外にも対応する、のではなく、わざわざ対応しないようにするのかと考える
これが典型で、「100%動く保証」が必要か、「99%動けば問題ない」とするかだ。
見た目動いているからいい、を是とするか非とするかとも言える。
テストで100%網羅できることはない。
バグが無いことを目指すのなら、対応している事が確認できなければ使えない。
Array.isArrayでそれが確認できるのなら、それは使える仕様だ。
クラスシステムモドキで頑張っているようだが、元々prototypeを拡張するように設計されており、
実際の所、それの方がどう考えても使い勝手がいい。
だから、prototype.jsが流行ったというのも分かる。
問題はプロトタイプ汚染が発生することで、
逆にいえば、ローカルプロトタイプが規定できて汚染が発生しないのなら、おそらくそっちの方がいい。
とはいえ、今でも手動で __proto__ 等を使って設計できそうではある。
誰もこれをしないのはまた別の問題があるのか？
jQueryにしてもバージョン混在の問題があり、もちろん回避策もあるわけだが、
そもそもjQueryをローカル読み込み出来れば問題なくなるはず。
システム的にはスコープチェーンを辿っていく方式なので、
関数単位でのローカルプロトタイプは出来るように思えるが。
@@toStringTagについては、誰かが書き換えた影響が自分にも出る可能性があるということだと思うが、
この手のプロトタイプ汚染っぽいものを言語的に排除できるようにして、
prototypeを自由に拡張するのが本来のJavaScriptの思想だと思うのだが。
元々一人で組むチョロスクリプト用だからその機能がなかったのは仕方ないとしても、
無理矢理クラスにしようとしていて手こずっているように見える。
ローカルプロトタイプの方が多分この言語的には似合うだろう。
誰もやろうとしていなさそうなのは、何か別の問題があるのかな？
無理やりArray的アクセスが出来るように見せかけただけのものというより、
DOMのコレクションはそれはそれで立派なArrayとは違う配列。
そしてslice等の破壊的メソッドが通らないのは、見せかけだからではなく、
凍結された配列だから破壊的操作を受け付けないから。（エラーは返す）
>>32
プロトタイプ汚染というのはビルトインを拡張するときくらいしか問題にならない。
それすらもES6モジュールで分離すれば解決するだろう。
それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
インスタンスベースと見た時のJSの思想だと思う。
ふむ。もう一度確認してみたがエラーにはなるようだ。
確認してから書いたのだが、どうやら間違っていたらしい。すまん。
> それと、自由に「.prototype」を拡張することではなく自由に「プロトタイプ」を定義できることこそが、
> インスタンスベースと見た時のJSの思想だと思う。
多分これは違う。
> 自由に「.prototype」を拡張する
これでは既存のクラスシステムと同じだ。
「自分で型を作れる」または「『新規の』型を自分で作れる」だけに過ぎない。
JavaScriptのプロトタイプベースは、「既存の」型を拡張できるところが違う。
ただこれを活用できるかはまた別だ。
これはMDNでも紹介されている。
> これはとても強力です。
> JavaScript では、プログラム上でいつでもどれかのプロトタイプを変更することができます。
> ということは、実行時に既存のオブジェクトに対して追加のメソッドを加えることができるのです:
> （中略）
> これは Person オブジェクトをデバッグするときに役立ちます:
> https://developer.mozilla.org/ja/docs/Web/JavaScript/A_re-introduction_to_JavaScript
ただしデバッグ時以外に活用する方法を誰も思いついていないのだと思う。
仮に鯖上で実行中であってもいきなり動作を変えられる。これは他の言語では出来ない。
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
> それすらもES6モジュールで分離すれば解決するだろう。
しかし@@toStringTagの件はそれだろ？
俺は「そんなの書き換える奴が悪い」で終わりだが、
それが許されないから ==='[Object Array'] では駄目で Array.isArray なんだろ？
ただ import で自由にビルトインも含めて拡張できるのであれば、
上記「禁忌」とされてきて開かずの扉になっている部分を、誰かこじ開けるかもしれない。
@@toStringTagを考慮してあげるか、そこまでしないかの差だというつもりで差があると言ったんだよ。
そもそもisArrayもProxyは通すからね。別にisArrayに通ったからといってそれがArrayの動作をすることまで保証されていない。
起源がArrayだという程度の意味しかない。
それで十分な場合も多いと思うが、より良い配列の判定がある場合も多いという話がしたかったのだよ。
あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
そういった行いを尊重しようとするか、しないかの判断ではないかな？
それとprotoypeというのはあくまでnew演算子が活用するだけのものであって、
それ以外に特別な意味はないし、プロトタイプベースの一角でしか無い。
一番大事なのはプロトタイプを変更できること。
それと動的変更は別に動いてる最中ではなく、変更をかけてから動かすという方が主だろう。
コンパイル言語ではなく、Web上で不規則かつ非同期にいくつものスクリプトが読み込まれ実行されるものなので、
何かを拡張したりするには、実際に動きながらするのが最も妥当な方法だ。
さすがにそれだと本当に書いているのか疑問だ。
色々ツッコミどころはあるが、一つずつ行こう。
> あと、ビルトインの@@toStringTagが書き換えられた場合というのを、良い悪いで判断するのも自分の感覚と合わない。
> そういった行いを尊重しようとするか、しないかの判断ではないかな？
ビルトインの@@toStringTagの書き換えを尊重する場合って、具体的にどんなケースがあるんだ？
俺はこれはコーディング規約で禁止にされるべき項目だと考えている。
「言って欲しい意見」を期待とはどういうことだ？
そちらがこちらの話した意図を正しく捉えて無かったようなので補足したまで。
そしてコーディング規約で禁止とかいうのが考え方狭すぎだろう。
JSはハックやパッチにも使うもの。
Arrayの@@toStringTagを書き換えたのなら、それ自体がほぼ目的の
それはArrayをStringTagで判定しているところに通さなくしたいというケースも有るだろうし、
一方大規模開発でStringTagに追加でメタ情報を付与して活用しようとするケースも有るだろう。
例えばArrayのStringTagを"Array:Any"とかにして、
int8型配列のを"Array:Int8"、他の自作配列を"Array:Hoge"にし、
デバッグや補助関数で活用するということも出来るだろう。
仕様の定義に根拠を置いているんだよね。
緩いJSとは言え本当にすべきでないようなことや悪いことは仕様で禁止されている。
逆に禁止されていないのであれば、原則活用することは罪ではないと考える。
例えばtoStringTagはWritableがfalseだから通常無意識に書き換えられるようなものではないが、
Configurableはtrueなので強い意志があれば書き換えて良いものとなっている。
一方コンストラクタのprototypeプロパティはConfigurableがfalseだ。
これはJSにおいてprototypeプロパティのないコンストラクタはコンストラクタとして最低限成り立たない、
もしくはprototypeプロパティのないコンストラクタはJSらしくないからだ。
こういった改変をしようとするのは悪だと考える。
まあ互換性によって残っている良くない仕様というのもあるので、全て価値観を仕様に頼って良いわけではないが、
toStringTagなんてものはES2015において新しくよく話し合われて入れられたものであり、
その様々なシチュエーションで使えるようにしてくれた意志は尊重すべきだと思っている。
これが土台で、勿論その上に事案毎にコーディング規約やらが来る。
Windowsがオープンソース化される予兆 - 阿久津良和のWindows Weekly Report | マイナビニュース
http://news.mynavi.jp/articles/2015/12/21/windows10report/
2015/12/21
何がやりたいのかさっぱりわからない
文字数は出来るだけ切り詰めて原則箇条書きとかね
一般論をダラダラやられても困る
具体的であればあるほど答えは誰が見ても決まってるのだから
そもそもその手の人達が一般的にどうしてそういう行動するのか共感ができないというから
その原理と一般的な信条、思考パターンを述べる展開になっている
C言語信者なのは、スピード命！スクリプトとかCPU資源浪費しすぎだろ！
って思ってるから。
そんな私が、手持ちAndroid７インチタブレットで漁業用GPSロガーを使いたくなって
Google Maps API を触ってみた。
凄え。。。
Javascriptでなんでもできるじゃん・・・まじかよ・・・
Androidアプリ書こうかと思ったけどJavascriptでいいわ。
PCからも見れるしね。
まだ航跡記録とかマーカー記録とか作ってない中途半端な状態だけど
休みの日に酒飲みながら機能追加していくの楽しすぎるｗ
http://www13.plala.or.jp/tarna/maps/ariakekai/index.html
有明海を見てね。
長崎県と熊本県の間の内海です。
漁業用のGPSが今もみんな日本測地系を使ってるので。
携帯もスマフォもGoogleMapも世界測地系なので変換してます。
見た。
てか、きっちり書いてあるなあ。
Cから見ればJavaScriptなんて超大富豪プログラミングだからね。
ただ、JavaScriptのユルさはなかなか良いとは俺も感じる。
ブラウザでお気軽GUIできるのもいい。
とはいえ、その規模で収まっているうちはいいが、
これからバシバシ機能追加していくのなら、JavaScriptのアレな点が見えて嫌いになるかもw
JavaScriptは今じゃ、ブラウザの言語でとどまってないからね。
１．Electronでマルチプラットフォームアプリを作成できる
２．CordovaでiOSやAndroidアプリを作成できる
３．Node.jsを使って、Raspberry Piのようなハードウェア制御ができる
４．同じくNode.jsを使って、PHPの代わりにサーバサイドの制御ができる
１粒で５度美味しいプログラミング言語です。緩いが故に大変な部分も
あるけれど、基本的にはライブラリを活用する事でその辺を軽量化でき
るしね。
嫌いな人も多いが、俺もnodejsの便利さにいまさらびっくりしてる。
eureca.io使って、クライアントとサーバが双方まるで直接呼んでるみたいにfunction呼び出しして、あまつさえコールバックまで出来るとは、とビビるくらい。
言語の弱点をライブラリ群がカバーしてくれてるから、助かるよね。
支持されていなかったら、そのライブラリ達もいないわけで。
あとは、プロトタイプベースで魔改造する余地があったのも大きいのかも。
普通の言語で、基底クラスを基底クラスのままメソッド追加するとか、上書きする、なんて今までの言語では頭おかしいって言われそうなユルさかつ、
言語仕様としてシングルスレッドじゃん→なんかコールバックさせる仕組みを外に持たないとね→実装
みたいな魔に魔を重ねた改造の結果、使いやすくなってるような気がする。
距離を計算するGoogleMapsライブラリに
グローバルで保持してる中心座標を渡したらエラー。。。
new 座標（global中心座標）して渡したら通る。。。どういうこと？
っていうか、渡す時も、受け取る時もnewしないとエラーが出ることがあるんだけどなんだこれ・・・
javascriptの仕組みを理解できてないね・・・orz
newで受け取った値を代わりに使ったら、前の値はメモリに残るだろうし
ガーベージコレクションは自分でしないといけないのかなぁ。
富豪だし無視してもいいかなぁｗ
もうちょっと遊びながら勉強してみます（汗
new Dateと同じだろ。
日付に見えてただのテキスト型になってるとかそういう事。なので、明示的に
型変換して入れてやる事はままある。
ｎ
物があるんだから具体的に何行目って言ってくれた方が分かりやすいとは思うけど、
見た目多分>>52であってる。
俺もそんなに詳しい訳じゃないし、APIの仕様も知らないけど。
ガーベッジコレクション(GC)をユーザが起動する方法はない。
参照が切れればいつか勝手に回収される。
ただ、見た目バカスカリークする可能性があるタイプのプログラムじゃないから、
多少リークしていたとしても問題ないと思うけどね。
リークが気になるなら、chromeならDeveloperTool、FFならabout:memoryで確認できる。
ちなみにそこにGCするボタンもある。
// グローバル変数
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さんが勝手に掃除してくれますよね！
currentPos={...}は、そのまんまcurrentPosに{...}を代入するだけで、
それぞれのプロパティに代入してくれるわけじゃないよ。
{...}自体が、new Object()だしね。
ガベコレが回収してくれるには参照を切ってやらなきゃならんのだから、null代入は必須。
意図的にnullを代入するとガベコレが回収する訳じゃないけど。
グローバル変数のcurrentPosはLatLngなんだから、{}でつっこむほうが間違ってる。
レス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上のひも付けにも苦労してます（汗
＃あぁあああなんでぇええ って腹たつけど、意図的に動いた時にはやっぱり嬉しいですよね
＃プログラミングって楽しいですよね！
既に指摘されているとおりだけど、
> 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を使えばいい。
正直、ブラウザ上でのプログラミングはかなり楽しいと思う。
GUIで具しか書かなくていいのでチャキチャキ感があっていい。
ただ、他の新しいGUIは知らないから、他にもいいのがあるかもしれないけど。
色々教えてくださってありがとう御座います。
ブラウザ上のプログラミングも楽しいですけど、
PC8801mkII-SRからプログラミングを始めた私としては、
限られたCPU速度、メモリー、直接ハードを叩いてる感、も楽しかったんですよ
V-Sync割り込みで画像移動させるとスムーズに動くとかね。
そういうハードの限界まで頑張る、的な楽しみは今では無いでしょうけど
Google Chromeには便利なデバッガーあるし、
ネット上には情報がいっぱいあるし、
今の若い人たちはjavascriptから遊んでもいいと思いますね。
html5のcanvasでゲームも作れるし。
文法的にはCにもjavaにも似てるからどこにでも進めるでしょう。
職業：プログラマーという選択が良いか悪いかは別としてねｗ
趣味：プログラムなら一生楽しそうだけどなぁ。
私はプログラムは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にできないと死にます。
スレチ、失礼しました。
キルリングの取り扱いが変わっていて慣れないし、
括弧閉じてもインデントが上がってくれない。
括弧の対応がハイライトされないのも謎だ。
まあもう少し使ってみるけど。
ただ、書いている最中に構文チェックするらしくて色が変わる。
これ自体は便利だと思うけど、どこまで使えるものなのかはまだよく分からない。
>>GCして欲しいのならnull代入するなりdeleteするなり関数で囲って関数ごと捨てるなりするしかないけど
それらでCGされる保証はない
エンジンは一般的な場合に最適化されてる
一般的でないことはしないのが基本
js2-modeは関係ありませんでした。
括弧の対応のハイライトはやはりおかしいままですが、
対応が間違っている場合はそもそも色が変わるので、
結果的にはあまり問題はないですね。
http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500
Array.prototype.filter.call(src.getElementsByTagName('a'),function(dom){return dom.textContent==='XXX';})[0];
で取り出せるんだけど、もう少しましな方法って無いかね？（速度および見た目的に）
条件は、
1. <a>は10個くらいで、5〜6番目が引っかかるので、そこでショートカットしたい。
2. 取り出すのは最初の1個でいい。
それを何度も実行する気なら状況によって要素や文字列をキャッシュすればいいし、
もっともっと短くしたいのならES2015を使えばいい
本当は、
querySelector('a[textContent="XXX"]')
と書きたいところだ。
ただこれは出来ないので、これまでは致し方なく別関数なりベタで書いていた。
しかし call に慣れてくると実は意外と使えることに気づく。
使い道の無かった filter も便利に使えるかと思ったのだが、
配列メソッドなのでショートカットが無いのが唯一残念なところだ。
（個人的には記述量は気にならない。）
大量の行の挿入くらいじゃ止まらないし、
そもそも一画面分以上挿入する必要もないだろ。
具体的に何行挿入して、どれくらいカクついたらアウトなのよ？
ここで詳しく回答する気は起きないので簡単にしかいわんけど
http://echo.2ch.sc/test/read.cgi/tech/1457452716/
>>65
XPathを使えば良いと何度もいわれてる
>>67
1行ずつ何度も挿入してるんだろ
DFを使え
グローバルじゃ意味無いよな？
引数で与えられるから動作としては問題なく、見た目だけの話だけど。
> forEach に thisObject パラメータが与えられると、callback の呼び出しのたびにそのオブジェクトが this として使用されます。thisObject が与えられないか null だと、callback に結び付けられたグローバルオブジェクトが代わりに使用されます。
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
現にアロー関数だったとき機能しないでしょ
currentValue が thisになるのなんて、
DOMのイベントハンドラの中でthisが要素になるぐらいのもんだろ。
そもそもDOMはJavaScriptではない。
そもそもDOMがおかしいんだよ。
> 現にアロー関数だったとき機能しないでしょ
あれはどっちかというと無駄な仕様変更だと思うが。
正確に言うと無駄な仕様を削除して新しく自動 .bind(this) に変更したわけだが、
その必要も無かった（と思う）
>>74
> そもそもDOMがおかしいんだよ
これはそう思う。というか、あれは this になることで無駄な手間が増えてる。
イベントハンドラを継承で与えるとき、(クラスでイベントハンドラを共有するとき）
いちいちインスタンスに bind しなくてはならないので面倒だ。
必要なら e.currentTarget でよかったのに自動 this だからこうなる。
ただここら辺も統一感がなくてイマイチではあるが、
現実的には何とかなる範囲ではあるので、（我慢できる範囲）
AltJSもイマイチ本家を殺しきれないといったところか。
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値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない
仕様「変更」ではない
アロー関数はより「ピュア」な新たな関数
newも出来ないし、thisやsuperも変数と同じように参照する
bindとは違う
統一感はある
DOMは関係ない、altJSでも同じこと
というかデファクトであってそれに依存するのは非推奨
指摘の通りDOMをイメージしていて、
これまた指摘の通り全部thisでやろうとすること自体が糞だと理解した。
> (arrayに束縛するならわからんでもないが)
確かにこちらの方が自然だね。(とはいえthisにこだわるのが間違いだったが）
> event.currentTarget === this は相互運用性の為に仕様に取り込まれたに過ぎない
見た目相互運用できるようには見えないが、
(thisに揃えても同じコードを再利用できるとは思えない。もちろん揃えないよりはマシだが）
後付けでいろいろ奇妙になっているのは理解した。
> http://7cc.hatenadiary.jp/entry/eventlistener-handleevent
> this値に変更されて困る重要なデータを格納する
jQueryは知らないが、これはconstの代りに使うということか？
アクロバティック過ぎる。
>>77
> アロー関数はより「ピュア」な新たな関数
つまり機能限定版か。
そういう理解は出来なくもないが、導入するメリットは文字数以外に何もないだろ。
そりゃ意味無いって普通は言われるよ。
どうせ新規にするのなら、クロージャ無しとかまで踏み込んでもよかった。
(新規なら使い分けが必要/有効なところまで機能分離するべき）
> 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オブジェクトの仕様と
互換性を持たせて実装されている。
高い互換性ではないが、それでも程度はあるから移行が楽になる。
> jQueryはthisをローカル変数でも引数でもない第三の格納倉庫として利用し、コード上でthis値が変更されることを許さない
> this値に変更されて困る重要なデータを格納するのが当然と思う風潮が一部で生まれている気がしないでもない
そんなことしません。
そう言う用途として使うのは、DOM要素のdatasetだよ。
このdatasetっていうのは比較的最近できたもので昔はなかった。
だけどjQueryは要素ごとの情報の格納場所の必要性を昔から認識していたため
datasetが作られるよりも前からdata()メソッドと言うのを持っていた。
そしてdata()メソッドがある理由の一つとして、
thisに直接値を格納するとブラウザのバグでメモリリークになる可能性があるから
「this（DOM要素）にデータを格納してはいけない。」と言っていたぐらいだ。
事実はあんたが思っているのと正反対だよ。
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.
handleEventはswitchでイベントを振り分ける必要があって使いづらい。
なぜこんな仕様があるかというと、そもそもDOMはJavaScript以外の言語も
考慮されて作られているという事実で説明できる。
つまり関数の引数、つまりaddEventListenerの引数に関数を渡せない言語が存在する。
具体的に言うとJava。Javaでは引数に関数を指定することができず、
オブジェクトは指定できる。
handleEventインターフェースを実装したオブジェクトを引数に取る関数と
考えるとhandleEventという仕様がなぜ存在するかがわかる。
これは便利だから追加された機能じゃない。Java等で必要だったっから
追加された仕様であって、JavaScriptでは関数をそのまま指定した方がいい。
> > 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 値を指定すべきではない
> jQueryは要素ごとの情報の格納場所の必要性を昔から認識していた
これは俺もすごく思うが、
実際のところはリークと速度低下が怖くてJavaScript側で持っている。
さすが実用ライブラリだけあって痒い所には手が届いているというところか。
>>82
> handleEventはswitchでイベントを振り分ける必要があって使いづらい。
これは何故？俺は使ったことは無いが、見る限りそういう感じではない。
イベントハンドラは基本的に直リンクというか、振り分け済みの関数を与えるのが基本で、
thisが効くオブジェクトを与えられるのなら、子クラスを与えればいいだけ。
当たり前だがオブジェクト指向の基本どおりだ。
また、最初からイベントハンドラ内で振り分けする気であれば、
ルートNodeにイベントつけてe.targetのclassで判定するのが自然だ。
何か別の条件ではまっただけの気がするが。
とはいえ、DOMの仕様がJavaScriptから見て中途半端なのはJavaとの相乗りが原因だとは理解した。
// 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 値が変動する事に価値を見出せる設計にする必要がある
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); });
> 事実はあんたが思っているのと正反対だよ。
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
thisはpythonのselfみたいに一定の規則はあるが
あくまで０番目の引数みたいなもんで何に使おうが勝手だし
そういうのを利用するならきちんと把握しないといけない
その程度のことに良いとか悪いとかはない
使いたいならただ受け入れればいいだけ
なんかよく分からんけど気持ち悪いみたいな
結局愚痴をダラダラと言いたいだけならもうここら辺でやめとけ
いちいちbindって書くの面倒
ここまで説明されて愚痴にしか読めないのなら口を出さなければ良いと思うけど
引数としてメソッドを渡す際は今だと
obj.method.bind(obj)
よりもアロー関数を使って
()=>obj.method()
の方が良いかもしれない
あとバインド基本にするのは結構簡単
クラスのプロトタイプにそういうプロキシを挟めばいい
アノテーションとか使えるようになればなお綺麗に書けるね
まあバインドシンタックスobj::methodとかもあるんだけどね
そういうのを使えるトランスパイラ使うってのも悪くないと思う
前半、言っていることは分かるんだが、現実的には、
this がDOMであるコードと自前のオブジェクトを this 参照するコードを
同一のコードで処理（相互運用）するためには、
自前のオブジェクトをDOMモドキにする必要があって、
（DOMと同じプロパティ等でアクセスできるように形を揃える）
これだと余計に苦労する。
だから結局、既に書かれたコードを流用することは難しく、
書き直すかラップしてしまうほうが簡単だ。
多分現実的には相互運用をしている奴は少ないのではないかと思う。
もちろんthisで共通アクセスできないとその可能性すらないからそれよりはマシだが、
現実的にはこの仕様はあっても使えない。
実際、>>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を生かして」 使うことになる。
当たり判定のグルーピングを細かく変更したいときはこのやり方が適するけど、
用途はあまり無いと思う。
e.currentTargetとthisの両方を異なる意味で用いている上記のようなケースをどうするかであって、
多分これはどうにもならんだろ。
手っ取り早いのはラップ関数内でthis値をMapなりから引っ張ってきてしまうことだが、
要するに書き換えが必要なので仕様をわざわざ合わせた意味がない。
何らかのために仕様をあわせたというのなら、
そのおかげで書き換えなくても済みました！がないと意味が無い。
DOM側からすると妥協だということだが、放置でもよかった気はする。（仕様として追認の必要なし）
なお、thisかe.currentTargetの片方しか使ってないコードは自動でも書き換えできる範囲だと思う。
しかしそうなると問題の出所はブラウザの実装で、
何故e.currentTargetに統一せずにthisを渡すことにしたかだな。
正直、あれ、thisで渡されても全くメリットないよな？
> DOM4で標準化された事で既存のコードが確実に動作する事が保証された
これは多分、気にする人にとっては重要なのだろうけど、
Webサイトなんて10年後の動作を保証されたところで意味が無いし、
「当面(数年）確実に動く」であれば大半の人にとって問題ない。
それが実装主体で推移している原因にもなっていると思う。
とここまで書いて気づいたが、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){},
};
いやそのjQuery.eachのthisは意味があるぞ。
それならthisで書かれたイベントハンドラをeachで回せる。（DOMのイベント寄り）
ただe.currentTargetで書くべきだというのと、
そもそも他に代替手段がありまくるので、割とどうでもいいが。
thisを固定したことによるデメリットの方が上回るかもしれない。
ただまあ、そちらの主張どおり、
thisに対しては緩く考える（○○が来ると仮定しない）方が何かと便利なのは事実だろう。
それ以上でも以下でもない
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的に分散され、特定のサーバーに依存しません
「
元々それ用だけどそれ以外に用途が無い。
もちろん発展させればWinnyやskypeみたいな事は出来るけど、それなら最初からそっちでいいし。
俺も最初知ったときは「ウッヒョー」だったけど、冷静に考えたら落ち着いた。
現実的には大半の事案は鯖立すればいいだけだからね。
技術的には面白いとは思うけど。
100〜のスレッドの続きを読む
