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

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

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

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

↓ こちらへどうぞ

【JavaScript】ｽｸﾘﾌﾟﾄﾊﾞﾄﾙﾛﾜｲﾔﾙ52【php,py,pl,rb】 [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1443578172/

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

JavaScript リファレンス - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference

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

(1) プログラミング既習者専用です。初心者の方はご遠慮下さい。（大事なことなのでry
　　ここで言う初心者とは、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.net/test/read.cgi/tech/1429634108/
ECMAScript デス 5 (ム板仕様スレ)
http://peace.2ch.net/test/read.cgi/tech/1449027632/
【超初心者用スレ】
JavaScript の質問用スレッド vol.127 (Web制作板質問スレ/頻繁に分裂中)
http://peace.2ch.net/test/read.cgi/hp/1448293871/

テンプレは>>1と>>4

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

[状況]
Web制作板はIDが出ないのでアフィカス/teratailerが暴れている感がある。
「1～10まで足す」みたいな質問にも回答が付くという奇妙さだ。
また、ライブラリ厨の意味無い布教活動も嫌がられている。
個人的には低脳アフィカスが一番の癌だと思うが、
奴らは印象操作が目的なので反論されても喚きちらすだけ。
もう超初心者スレとして分離するしかない。
回答する奴も初心者なのでデタラメだらけだが、あいつらにはそれでも問題ない。
明らかに間違っている事を正しいと言い張る馬鹿共を矯正する方法は2chにはない。

ム板の質問スレはIDが出るので、逆に言えばIDが出て困る奴はいない。
ほとんど流れていないが、質問すればWeb制作板と同レベル以上の回答は付く。
まともな回答を期待するのならこちらに投稿した方がいい。ただし回答が付くまで時間がかかる。

Web制作板の方はIDが出たら困る奴が「流れているスレ」として見せるために無理矢理流している感がある。
このため、上記のように、ただ単に無視すべき投稿にもレスが付く、どうしようもないスレになっている。
また、どうでもいい一般論を投げかけ、無理矢理流そうとしているものも散見される。
やりたい放題やられているわけだが、しかしその先には何もないように思えてならない。
何がやりたいのかはかなり疑問だ。ただ、止める方法もないので、分離するしかない。

仕様について厳密に詳細を確認したければECMAScriptスレがいい。
正直、他も含めてJavaScriptスレ住民の仕様に対するこだわりは異様だと思うが、
逆に言えば、厳密に議論したければ相手はそこにいる。
ただしそいつらは仕様にはすごく詳しいが、コードは記述していないらしく、
何が本当に問題なのかを実感できていない。
だから地に足のついていない議論になってしまう。
とはいえ、詳しいことは事実だ。だから仕様について正確を期すのならそこがいい。

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

以上、どうしようもないスレばかりなので新しく「プログラミング既習者専用」スレを立てることにした。
現時点でまともな奴がほぼいないので、新しく訪れてくれる人を待つことになる。
気長な話になるが、やらないことには始まらないので、とにかく始めることにする。

3,000行についてだが、OAOOはもちろん徹底しているとして、
1,000行なら勢いで書いてしまえる規模だ。
ところが3,000行となると、内部構成をある程度マトモに設計していないと破綻し始める。
逆に言えば、内部設計を正しく行い、かつ実装できる人の目安として3,000行を楽々、とした。

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

[状況追加]
11/28に立てたスレ（同スレタイ）
http://peace.2ch.net/test/read.cgi/tech/1448714123/
が何故か1週間で落ちたので、もう一度立て直した。

2ヶ月以上書き込みがないスレもこの板にはあるので、書き込みが無くて落ちたわけではなさそうだ。
削除依頼も確認してみたが、該当はなかった。
質問スレがvol118, vol124と完全に被っているのに放置されているため、重複削除でもない。
原因が不明のため、とりあえず再び立てて様子見することにした。

一応7日ほどは持っていた（はず）なので、4-5日程度毎に俺が話したい案件を上記前スレ
http://peace.2ch.net/test/read.cgi/tech/1448714123/4-7
からコピペしてきて落とし、これでしばらく持たせる。
もちろんそれ以前に話題があれば勝手に開始してくれて構わないし、
俺の案件についてレスを付けてくれれば応じる。

このスレの狙いは、まずは人を集めることだ。だから半年以上持たせる必要がある。
あの質問スレの状況だと、まともな上級者はウザがって寄りつかない。
上級者を集めたいのなら、彼等にとって読む価値のあるスレを用意して待たなければならない。
これには時間がかかる。機能するには半年以上かかるだろう。
しかし、やらないことには始まらないので、とにかく始める。

出来るだけ落ちないように努めるが、いかんせん基準が分からないのでまた落ちるかもしれない。
その場合は再び立て直すが、それにしても落ちまくるのは問題なので、
基準を知っている人がいたら教えて欲しい。

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

>>7
10レス未満だと落ちるよ

**デフォルトの名無しさん** · 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もちょっと書き換えたほうがいい気はするが。