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

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

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

**デフォルトの名無しさん** · 2016/05/14(土) 22:17:11.45

>>150

> 多分な、Web系の奴らが勘違いしているのは、「Webは特別だ」と思っていることなんだよ。君も若干そんな感じ。

Web系じゃないやつが勘違いしているのは、
「Web系の奴らがWebは特別だと思っている」はずだと
思っていることだよ。

誰も特別だと思っちゃいない。
お前には特別に見えるのか？
ならお前が特別だと思ってるんだろ。

**144** · 2016/05/15(日) 05:38:37.51

>>146-
まあAppCacheは（一応JSへのAPIもあるがそんなに使われていない）
あくまでキャッシュなのでいきなり削除しても問題になることが少なく
特例的に極めて廃止しやすい方だ。（廃止される）
他のAPIも、LSが広まりだしてから非推奨を設定しやすくなった。

しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
開発者やそのための解説情報作者のモラルを高めないことには難しい。

とは言え、１０年も経てば流石にどんな仕様でも削除出来ると思うよ。
ただ、EWMの夢物語でさえ東京オリンピックのころかなというイメージだ。
１０年は自分にとってWebにおいて永遠と等しいように感じる。

**デフォルトの名無しさん** · 2016/05/15(日) 09:04:33.00

>>153
> １０年は自分にとってWebにおいて永遠と等しいように感じる。
これでいいんだよ。逆に有限で廃止すると混乱する。

> １０年も経てば流石にどんな仕様でも削除出来ると思うよ。
どんな糞仕様であっても放置しているだけでは削除できない。
typeof(null) が object なのを削除できてないだろ？
あるいはthisがグローバルになるという糞仕様も削除出来てないだろ。
この2つなんて、ただのバグの温床であって、活用できるものではない。
ではデフォで"use strict"にできているかというと、これも出来てないだろ。
そういうものなんだよ。

Webの仕様で、ただの案ではなく、完全に「正式仕様」として認識されたもので、
「正式に廃止」されたものがあるかい？
上記を見る限り、使われなくなったものは多々あっても、「正式に廃止」されたものは無いんだと思うよ。

> しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
> ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
まあこれは一概には言えないけどね。chromeはJavaを切ったろ。無視できるレベルではなかったと思うよ。
実際に、俺は偶に遭遇するしね。
これも「正式に廃止」したのではなく、勝手にサポートを止めただけだ。
事実上の廃止勧告であったとしても、仕様から「正式に廃止」することは無いのだと思うよ。

本来、仕様策定とは、こういった混乱を防ぐためのものだ。W3Cは全く機能していない。
この点については、
>>131
> （昔的な）標準機構（形・影は薄れてきてる）はこれから何をするのがよいのか。
WHATWGは新仕様の採用には積極的なのだから、もうそっちは完全に任せて、
W3Cは旧仕様の削除に専念するのもありだと思うよ。
後者は要するに利害関係者間の調整であって、WHATWGの連中がやりたがる仕事ではないし、
本来の「仕様策定」側の仕事でもあるから。

**デフォルトの名無しさん** · 2016/05/15(日) 12:44:09.17

何で削除出来てないかって、単純に
破壊的仕様変更は許さないだけでしょ。
言語仕様を変えるのもまずありえないけど、デフォルトを変えるって実運用では禁じ手じゃん。
だから、これはvいくつですよ、って宣言書いて、非対応であればハネる仕組みを充実させるしかないし、ポリフィルが要らなくなることは無い。

**デフォルトの名無しさん** · 2016/05/15(日) 13:47:01.97

ブラウザのJavaScriptの特殊性を分かってないんじゃないだろうか？

開発した時のJavaScript実行環境と
違うバージョンの実行環境で動かすことだってあるのが
ブラウザのJavaScriptなんだが？

実行環境は互換性を保っていなければいけない。
当たり前の話なんだがな。

コンパイル言語で言えば、ある機械語の動作を
変えてしまうってことだよ。

**144** · 2016/05/15(日) 16:58:58.26

>>151,154
昔は知らないが今のバージョンのXHRは試したが304が最初から見えるはずだ。
優先度については自分もこの間も悩んだばかりだ。
XHRの進化は終わっているが、Fetchの方などでそこの部分は議論されているので見込みはあるかもしれない。
Fetchでは一応今のところリクエストには優先度というパラメータがある。（ユーザーエージェントが決める）
というとこまで決まっている。
まあ、みかけ上帯域制限するだけならStreamAPI使えば今でも出来るんだが、
帯域制限することも考えたAPIでないから、このAPI上でストリームを絞ったところで
実際ブラウザやOSがそれに従うという保証がないのが残念なところ。

DOMの一部分のレンダリングを止めるというのはちょっと難しいかも知れないが、
一旦スタイル指定で隠すというのが今のブラウザに対するそう言ったメッセージで、
そうしておくと無駄な処理は省略してくれる。
もしくは、DOM及びそれにアクセスするJSのプロセスを分けるという試みが為されているので
その延長上で期待するような状態が作れるかもしれない。

そして機能の正式な廃止だが、HTML5以前は独自実装およびデファクト仕様の山で、
HTML5になってから多少は整理したが未だ漏れてるものも数多くあるので、
廃止されるとなっても、それは機能の廃止というより独自実装の取りやめ、標準への追従に見えるということ。
実際にはshowModalDialogとかそこそこメジャーでも各ベンダーが一生懸命廃止させた仕様は幾つもあるし、
人知れず消えてったマイナーな仕様、挙動は沢山ある。

**デフォルトの名無しさん** · 2016/05/15(日) 17:01:58.55

>>154
'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
typeof nullの挙動は２年前治そうという案の盛り上がりが頂点に達したのだが互換性のために断念した。
が、将来的な演算子オーバーロードの仕様が入ると共に直す策を入れようと言う案は出てる。
もしくは、V8が画策している型付厳格JSの方向性が成ればそちらでも更生は可能。

でも自分としては、動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
その代わり、せっかく備わっている暗黙の型変換を利用して、型を「揃えて」おくのが良いと思う。
例えば自然数入力を期待してpromptを出し続けるのであれば、
do{
n = prompt('自然数') | 0
}while(n <= 0)
で良い事が多いし、良いとするようにする。
この場合入力がキャンセルされた際のnullも、空入力の""も+演算子で0になる。
そういうパターンを活用し、そういうパターンが活用できるようなロジック・仕様を組み立てるのが、
JSをスクリプト言語として上手く活用していく上での１つの答えと思っている。

そういう感じで、nullに関して重要なのは、もっとよく扱えるようにする事かもしれない。
例えば昔から案があって、直近はそろそろ仕様に入りそうなくらい盛り上がってきたこれ
https://esdiscuss.org/topic/existential-operator-null-propagation-operator
こういう演算子が入ったりすれば、ますます「事前にチェックする」必要性がなくなる。

**デフォルトの名無しさん** · 2016/05/15(日) 17:04:24.78

誤字脱字や凡ミスは良いように解釈してくれ。スマヌ。

**デフォルトの名無しさん** · 2016/05/15(日) 17:51:57.74

そういえば asm.js については、本当にこれが必要だと思っているのなら、本格的に型を導入したほうがいい。
someVariable = someVariable | 0;
の代りに
function(int32 someVariable){
また、
var someVariable;
の代りに
int32 someVariable;
double64 someVariable2;
だ。というか、asm.jsはかなり中途半端な仕様で、本格的に型が導入されてたら完全にゴミになるだろ。

この記法だと、当然JIT側の対応が必要となるので、
周知徹底、つまり「仕様として正式通達」が必要だし、浸透する時間も必要だ。
ただ、JITの改変自体は、宣言部は functionDecSrc.replace(/int32|double64/g,'');
中身は functionSrc.replace(/int32|double64/g,'var');
を頭につけるだけだから、やる気だけの問題だ。
政治的に問題なく、大手の協力さえ得られれば、1年でいける。
本来はこういう「関係者間の折衝」含めていい仕様を策定するのがW3C等の仕事だ。

**デフォルトの名無しさん** · 2016/05/15(日) 18:16:01.44

>>160
アホか。パーサ書いて文脈見ずにreplaceなんかで解決できねえよ。

**デフォルトの名無しさん** · 2016/05/15(日) 19:03:27.04

>>157
> 昔は知らないが今のバージョンのXHRは試したが304が最初から見えるはずだ。
いや、見えんぞ。Vistaなんでアレなんだが、
chrome 50.0.2630.1 canary SyzyASan と FireFox 45.0.2 だ。
もしそちらで確認できるのなら、環境を教えてくれれば助かる。
Flags等の設定をしているか？俺は全くしていない。

一応確認だが、DevToolsやFireBugで 304 になっているリクエスト結果に対し、
JavaScript側から XMLHttpRequest.status で確認すると 200 になっているということだ。
アップデーターを実装したとき、304ならその時点で処理を止めたいのだが、
全部200に化けているからこれができない。

**デフォルトの名無しさん** · 2016/05/15(日) 19:54:18.43

>>162
http://httpstat.us/304
に対して試してるんだけどそれらの環境で304取得できるよ。
こういうコードで。
xhr = new XMLHttpRequest
xhr.open('get', '304')
xhr.onload = () => console.log('status', xhr.status)
xhr.send()

**デフォルトの名無しさん** · 2016/05/15(日) 19:55:03.02

おっと、
xhr.open('GET', 'http://httpstat.us/304')
にしとくか

**デフォルトの名無しさん** · 2016/05/15(日) 20:00:25.76

> Fetch
見てみたがよく分からん。
ただ、帯域制限したいのではなく、本当に必要なものを順に取得したいだけなんだよ。以下とも絡むが、
> 一旦スタイル指定で隠すというのが今のブラウザに対するそう言ったメッセージで、
これは display = 'none'; だよな？これだと確かにレンダリングはされないのだろうが、
その中に<img src='XXX'>があると src をとりにいくんだよ。
結果、この明らかに表示に関係ないリクエストでXHRが待たされてしまう。
また逆に、表示する<img>のsrc取得も、大量にXHRを打ち込んだ後だと待たされてしまう。
これはモロに表示が遅れるので丸見えになる。
自動でやってくれるのが一番いいのだけど、多分それは無理なので、（XHRが表示に関係するか判定できない）
少なくともユーザー側で「今欲しいかどうか」を指定する必要がある。

> DOMの一部分のレンダリングを止めるというのはちょっと難しいかも知れないが
いや、一部分ではなく全体を止めていい。
アップデータで更新部分を差し込む際、結果的にばらばらの位置に差し込まれるときがあるんだよ。
ただ、差込自体は一度に行われるし、全部差し込んでからレンダリングでいいので、全体停止でいい。
多分ダブルバッファ的なものをやりたがる奴も出てくるはずなので、どの道必要になるとは思うのだが。
今のDOMはレンダリング制御用のAPIが全く無いんだ。
（とはいえ、速度にこだわらなければ無くてもいいんだが）

> Null Propagation Operator
これは好みだろうな。
if (a && a.b) a.b.c = d;
を
if (a?.b?.c) a.b.c = d;
と書けるという事だろうけど、こんなところでタイプ量をケチってもしょうがないし、
バグってても見た瞬間修正できるので、正直どうでもいい。

**デフォルトの名無しさん** · 2016/05/15(日) 20:08:28.09

>>163-164
サンクス。こちらもそのコードで304を確認した。
ただし俺のスクリプトでは確かに304が200に化けている。
原因究明には少し時間がかかりそうだ。

**デフォルトの名無しさん** · 2016/05/15(日) 20:45:26.55

>>158
> 動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
流儀があるのなら好きなようにすればいいし、コーディングルールに引っかからなければいいとは思うが、
それは一般的にはトリッキーだと言われると思うぞ。

null と　'' を弾きたいのなら、普通はチェック部分に纏めて以下にする。
do{
n = prompt('自然数');
} while(!n || n <= 0)
知ってないといけないことは、null は偽(常識）, '' は偽(JavaScript特有)だ。
前者は他言語でもそうなので、後者だけ知っていれば済む。

それに対して、君のコードは
1. null | 0 の結果がどうなるか(JavaScript特有)
2. '' | 0 の結果がどうなるか(JavaScript特有)
を知っていなければならない。自動型変換後のビット演算だ。かなり仕様の隅っこ。
そしてそれは制御論理とは本質的に関係ない。
つまり「JavaScript知ってる俺カッケー」でしかないんだよ。

しかも、論理構造に無駄があるだろ。
俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。

だから無駄に難しいコードになっているんだよ。
それで速度等のメリットがあればいいんだけど、今回については無いと思う。したがって、糞コード扱いされる。

君は無駄に3倍難しいコードを書いている。
それは、俺のような単純明快なコードを書くように勤めれば、同じ労力で3倍の規模のコードを扱えることを意味する。
君のやり方だと能力の2/3をみすみす捨てているようなものなんだよ。勿体無いだろ？

**デフォルトの名無しさん** · 2016/05/15(日) 20:52:38.61

>>158
> 'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
確認した。現実的にはこれで問題なさそうだな。
http://stackoverflow.com/questions/31685262/not-recommended-to-write-out-use-strict-with-es6

**デフォルトの名無しさん** · 2016/05/15(日) 22:01:03.99

>>163-164
どうやら強いEtag + nginx + gzip の場合に駄目らしいと分かった。
俺のスクリプトで化けているサイトも該当している。
> https://github.com/rtomayko/rack-cache/issues/111
しかしこれはこちらではどうにもならんな、、、、

とりあえず、XHRの問題ではないことは確かなようだ。

**デフォルトの名無しさん** · 2016/05/15(日) 22:04:49.13

>>165
優先順位を粗方決めたいだけならServiceWorkerを使えば可能そう。

>>167
つまり何が言いたいかというと、
n = prompt('自然数')
↑
（この型は何だ！？？）
という状態のまま処理を出来る限り進めないということ。
もっと言うと、「n」なのに数値じゃないかもしれない可能性を作らないこと。

このnをあちこちのサブルーチンに配ればあちこちで型に対するチェックや配慮が必要になってしまう。
そうではなく、もうなるべく早く、できればもう変数に最初に入れる前くらいに取りうる値を出来る限り狭めておく。
そうして置けば以降そのnについて心配しなくていいし、そういうのを徹底しとけば
いろんなサブルーチンを書いたり使うときも、引数の扱いで心配することが減る。

JSにおいて型周りで一番多く、かつデバッグが困難なのは、
数値と文字列、そしてそれにパターンマッチが絡んだりする場合だと思ってるので、
特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。

どうでもいいが、変数や引数の型が一定になることはエンジンにとっても優しい。

だがそれで長々とやってたら動的型付け使ってるのが馬鹿みたいなので、
自分は暗黙の型変換（''+、+、|0、のようなもの）を活用する。
まあ「Number(str)」でもいいが、「parseFloat(str)」は嫌いだ。

**デフォルトの名無しさん** · 2016/05/15(日) 23:44:52.60

>>143
こいつダメだ

**デフォルトの名無しさん** · 2016/05/15(日) 23:55:13.32

>>170
> ServiceWorker
とりあえずhttps限定の時点で使えない。
気持ちは分かるがそこはユーザに選択させろよなと。

ただchromeが勝手に読みにいく<img>に対して優先かそうでないかを指定できないと意味が無い。
自分が打ち込むXHR内での優先順位ではないんだ。
ただそれ以前に優先順位のつけ方が見当たらないが、どれ？
https://developer.mozilla.org/ja/docs/Web/API/Request

**デフォルトの名無しさん** · 2016/05/16(月) 00:26:42.96

>>170
主張は分かるがそれは完全に「型あり」の考え方だからな。
そうしたいのなら、「型」を導入してキャストするのが一番いい。
つまり、

Int32 n = (Int32) prompt('自然数');

となる。どう見ても Int32 にしかなり得ないと、一目で分かる。

ああ、だからそういった意味で言えば、 asm.js はキャストでもよかったのかも。
彼らは value | 0; で Int32 にキャストしているつもりなのかもしれないが、
それはビット演算を絶対にしない人の感覚であって、
実際にビット演算を使用する人の場合、あの記述だと混ざってしまうのでよろしくないんだよ。
とはいえ、JavaScriptの通常の使い方でビット演算が必要なことはかなり稀なのだけど。

> 特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。
いやこの必要なくね？APIは期待した型を返してくるし、そこで引っかかった覚えは無い。
'px'が付いている連中は若干うざいけど、バグったらすぐ分かるし。

ただやっぱ君は「型あり」向きだと思うよ。俺もだが。
var 禁止で全部 Int32, double64, string のどれかに差し替えろといわれても大して不満無いだろ。

**デフォルトの名無しさん** · 2016/05/16(月) 05:31:59.61

>>172
HTTPS必須は、「Let's Encrypt」が一般的に広まって、もっと道入が楽になることに期待する。

SWはXHRに限らず、あらゆる通信をプロキシできる、そしてその種類（image等）が分かるので、
例えばページが開かれてから200msの間全てを保留して、
その間に溜まって、その後も溜まっていくものから優先度の高いと思うのから捌いていけばいい。

ただこれではimg間での優先度が付けられないのでそこは工夫する。
一番簡単なのはhashを使ったりURLに情報を入れる事だろう。（src='～.jpg#high'）
もしくはページ自体の取得もSWを通じて行われるので、もっとアグレッシブにHTMLを解析してリクエストが来る前に読み込んだり、
初回開いたときにリストを作っておいて、次回から利用するとかいろいろ考えられる。

**デフォルトの名無しさん** · 2016/05/16(月) 08:47:49.06

横から口を出すが

>>173
結局、>>167の主張はスルーして「ToInt32(null) === 0 を知っていなければならない」の前提でいいのか
俺としてはES6の標準関数も型変換されているから「型変換ルールは知っていなければならない」で当然だと思うが

Math.min(null, 1); // 0 (「ToNumber(null) の結果がどうなるか」を知っていなければならない)
Math.min('', 1); // 0 (「ToNumber(null) の結果がどうなるか」を知っていなければならない)

それから>>158は型付を否定しているわけではなく、「事前にチェックするのが良くない」とする考え方だ

function hoge (int32 n) {} // 事前にチェックするので bad
　↓
function hoge (i) { var i32 = ToInt32(i)); } // 事前チェックは通過するが、後で型変換する
function hoge (i) { int32 i32 = ToInt32(i); } // 同上(型付でも考え方は変わらない)

長すぎる云々は>>158がES6範囲内で動くコードを書いているのに対してあなたがこうあるべき新仕様と対比しているので当たり前
短くしたいのなら

function hoge (toint32 i) {}

でも作り上げればいくらでも短くなるだろう(自分で短い仕様を構想すれば良いんだから)

**175** · 2016/05/16(月) 09:11:44.49

>>154
HTML5でかなりの要素が廃止された
http://momdo.github.io/html51/obsolete.html#non-conforming-features
CSS2.1ではかなりの仕様変更がなされた(削除ではないが、変更でも現行CSSには影響力があるものだ)
http://www.d-toybox.com/spec/CSS2.1/appendixC/index.html

削除ではないが、追加する事で影響を受けたのがtypeof演算子
ES6でSymbol型が増えた事でObject型のチェックが面倒になった
Object (host and does not implement [[Call]])は規定文字列以外の全ての文字列値をとり得るが、"symbol"が追加された事でtypeof arg === "symbol"がObject型ではなく、Symbol型となった
実際、ES6でもType()に相当する機能がないんだよな...
http://ecma-international.org/ecma-262/5.1/#sec-11.4.3
http://www.ecma-international.org/ecma-262/6.0/#sec-typeof-operator

**デフォルトの名無しさん** · 2016/05/16(月) 12:29:46.57

そういえば、lodashのisObjectは未だに"object", "function"しかチェックしないな
https://raw.githubusercontent.com/lodash/lodash/4.12.0/dist/lodash.core.js

function isObject(value) {
var type = typeof value;
return !!value && (type == 'object' || type == 'function');
}

**デフォルトの名無しさん** · 2016/05/16(月) 15:12:30.62

なんでそういう実装になってるんだろう？
function isObject(value) {
return value === Object(value)
}
の方が素朴で良い実装じゃね？

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

まあはやくReflect.isCallableとか追加されて欲しい、
ダックタイピングぽく、型より機能としてチェックするほうがいいと思う。

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

>>174
それはやれば出来るかもしれないが、「制御のための制御」になるので駄目だ。
別の言い方だと、それにかかる労力の割りに得られる結果がショボ過ぎて駄目だ。

そこらへんもやはり君はCの感覚なんだよ。「やりきれば出来る」というのがそう。
LL言語だと、「面倒なことは事はやらない」なんだよ。その分動作は遅いけど、手抜きが出来る。
そしてこの手抜きが出来る分、大規模なプログラムを扱うことが出来、
結果的にもっと大掛かりなこともできるという利点につながるんだよ。

分かるか？
勝負するところが違うんだ。
Cのような行単位でチューニング済みの最速コードを目指すのではなくて、
積極的に手を抜いて、結果的に規模の限界を突破することを目指すんだよ。
Cで10k行のコードを扱えるのなら、LL言語では30k行のコードを扱える。
当然やれる範囲が広がるだろ。
JavaScriptは簡単だから馬鹿でも扱えるというのは事実だけど、そこで留まるのではなくて、
それを達人が使ったら何が出来るのか？を目指すんだよ。
普通は「早く仕上げる」ためにLL言語なんだが、それだけではないんだよ。

**デフォルトの名無しさん** · 2016/05/16(月) 23:32:06.76

>>175
> 長すぎる云々
まず文盲で無いことを示してもらおう。これは具体的にどこのことだ？
俺は長さについては問題にしていない。

文盲を相手にしてもどうせ読み間違えまくってくるので議論はどうやっても空回りする。
これはもう既に学んだ。

**デフォルトの名無しさん** · 2016/05/16(月) 23:37:53.21

>>181
>>167の下記だろう

俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。

**デフォルトの名無しさん** · 2016/05/17(火) 02:50:45.73

> 弾かれる対象を確認するためには、whileの1行を見れば済む。

一行で書けば同じでしょ？

弾かれる対象を確認するためには、どこかの1行を見れば済む。

**デフォルトの名無しさん** · 2016/05/17(火) 03:25:50.15

それに一行に複数の意味を込めたらだめだよｗ

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

>>180
確かに個人的にはそういうコードを毎回書いても楽しいから苦にならないのだが、
何もそうしろと言いたかったわけではなく、一般的に利用するときは
ただそういうフレームワークを読み込んで、各リソースURLに「#priority」を付けるだけ
ってのは十分労力の割に結果がデカイと思うよ。

WebやJSの歴史見ても、「面倒なことは事はやらない」ってより、
「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。

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

>>167は null, '' しか考慮していない時点でダメ
"123hoge" を撥ねない時点で期待通りに動かない(自然数以外も代入されうる)

**デフォルトの名無しさん** · 2016/05/17(火) 14:54:21.35

一番ヤバイのはnが文字列であることだろう
後々必ず問題を引き起こす

**デフォルトの名無しさん** · 2016/05/17(火) 17:31:09.24

>>167は仕様理解者に恨みでもあるのか
「JavaScript知ってる俺カッケー」とか偏見にしても度が過ぎていると思うが

**デフォルトの名無しさん** · 2016/05/17(火) 19:36:20.35

分からんな
演算子による暗黙の型変換を一通り覚えるのは
中級者への登竜門でそれほどハッキーなこととは思えん
Dateのインスタンスだけはプリミティブ化されるとき、
valueOfよりもtoStringの方が先に呼ばれるみたいなことを
前提なコーディングは流石に万人向けではないと思うが

**デフォルトの名無しさん** · 2016/05/17(火) 22:07:15.55

暗黙の型変換は標準メソッドでも行われている事だし、それを覚えずしてJavaScriptを使うっていうのはなあ..
>>158の問題点は ToInt32 されるから 9007199254740991"|0 === -1 になる事だが、>>167の問題に比べたら些細な問題だ
これは Math.floor を使えば解決できる

do {
var n = Math.floor(pronpt('自然数'));
} while (n >= 0)

Math.floor() の暗黙の型変換(ToNumber)が「JavaScript特有」な論理をふりまくなら Math.floor(Number(pronpt('自然数'))) としてもいいが、正直冗長だと思う

**デフォルトの名無しさん** · 2016/05/17(火) 23:41:38.85

>>185
> 「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。
正確に言えば、「やるとなると面倒だが、普通はたいていの人が必要とすることは、ライブラリやフレームワークがやる」だ。
これはWebに関わらずプログラミング一般だ。それがライブラリ/フレームワークの存在意義だし。

> 各リソースURLに「#priority」を付けるだけ
になっているライブラリ等が既にあるのかい？それなら確かに導入する意味がある。
それはどれだか教えてくれないか？
（ただ、多分俺の環境では実際に導入することは出来ないが）

いずれにしても、「がんばってまでやりきる」為の言語ではなく、「がんばらずにやれる範囲でサクッとやる」なんだよ。
既にライブラリやフレームワークがあるのなら、「がんばらずにやれる」のでサクッといただきだ。
そういう奴らが多い＋プロプライエタリには極度にしにくいから結果的にいろいろ乱立することになるが、
それはある意味正しい姿といえる。
少し無駄や気に入らない部分があっても、自前で作り直すのではなく、面倒だからそのまま使う、だ。
その1メソッドの中での最適化で勝負するのではなく、
もっと大きい範囲での最適化（サクッと結果が出せるか）で勝負するんだよ。

あと追加。
https://developer.mozilla.org/en-US/docs/Web/Events/scroll
scroll の e に delta がない。
だから糞遅い scrollTop の問い合わせがいちいち必要になる。
.NETだと e.delta でどっち向きにどれだけスクロールしたかが取れる。
同様のことはmousemoveにも言えるのだけど、
あっちは clientX とかがあるから、DOMクエリしなくても追跡できる。
scrollはDOMクエリを強要されるのが辛い。
サンプルも window.scrollYを取っているけど、アレは実は結構重い。
そしてそれがサンプルにあるように、大抵の場合はスクロール位置の確認が必要になる。

**デフォルトの名無しさん** · 2016/05/17(火) 23:42:45.65

Math.floorを使ってもdoubleで扱える範囲でないと仕方ないのは変わりない。
入力が適切に処理できる範囲に収まっているか確認し、大きすぎます等の案内を出す必要がある

**デフォルトの名無しさん** · 2016/05/18(水) 00:08:03.84

>>185
あと、ついでならMDNもお願いしていい？

1. https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date
内のメソッド parse について、
× > JavaScript で日付を表す文字列を解釈して、地方時で 1970 年 1 月 1 日 00:00:00 から経過したミリ秒を表す数値を返します。
○ UTCで

**デフォルトの名無しさん** · 2016/05/18(水) 00:09:05.81

>>185
2. https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test
test がさも search や exec の代りの高速メソッドとして使えるように書いてある。
これは半分事実なのだが、実際はtestはexecを1回やるだけなので、RegExpをバッファするとバグる。
具体的には以下。2回の同じ入力の呼び出しに対し、出力が異なる。
(testinputはそのページの使用例の出力先をconsole.logに書き換えただけの物）

function testinput(re, str) {
var midstring;

if ( re.test(str) ) {
midstring = " contains ";
} else {
midstring = " does not contain ";
}

console.log(str + midstring + re.source);
}

var rexp = /a/g;
var str = 'abc';
testinput(rexp,str); // abc contains a

testinput(rexp,str); // abc does not contain a

これは完全に落とし穴掘っているだけで、MDNだけ読んでいても気づかない。
だから「testは実際はexecを1回起動するだけです。詳細はexecを確認してください。」みたいな誘導が必要。
testに渡す正規表現に g つけんな！ってのはあるけど、
管理上、同じ正規表現を使いまわししたいときがあって、（その正規表現はプログラム内で1箇所にしたい)
そのときに g が付いているやつがあってバグった。
だから、「gつけないでください」という誘導でも実質的にはいいのだけど、多分MDNの雰囲気とは合わない。

**デフォルトの名無しさん** · 2016/05/18(水) 00:33:18.17

>>192
そりゃそうだが、随分面倒な処理を要求するんだな
Number 型全体が IEEE 754 の制約を受けるわけだが、制約外の数値を正しく検出するようにしろという事か
対処療法的には入力文字列を正しくパースして数値比較する
根本的には ECMAScript のビルトインオブジェクト全体を書き換える必要があるわけだが、そこまでやる必要あるのかね

**デフォルトの名無しさん** · 2016/05/18(水) 01:11:57.83

>>195
君の言う問題点とやらを解消するためにはそこまでやる必要があるというお話さ
そしてそんなに難しく考えなくともdoubleとして受け取るのならNumber.MAX_SAFE_INTEGERを超えてないかどうかチェックすればいいだけ

**デフォルトの名無しさん** · 2016/05/18(水) 22:06:18.60

>>196
なるほど、理解した

**デフォルトの名無しさん** · 2016/05/18(水) 22:43:30.32

修正版

do {
　var n = Math.floor(prompt(Number.MAX_SAFE_INTEGER　+ '以下の自然数を入力してください'));

　if (!n) {
　　alert('数値となる自然数を入力してください');
　} else if (n < 0) {
　　alert('負の数は指定できません');
　} else if (n > Number.MAX_SAFE_INTEGER) {
　　alert(Number.MAX_SAFE_INTEGER + '以上の数は指定できません');
　}
} while (!n || n < 0 || n > Number.MAX_SAFE_INTEGER);

**デフォルトの名無しさん** · 2016/05/18(水) 22:49:59.30

誰が完璧な自然数受け付けのロジックを長々と書けといった……
そこまでするなら多長倍数ライブラリ使ったら？

**デフォルトの名無しさん** · 2016/05/18(水) 23:38:34.48

>>199
初めは while 条件だけで終わらせる予定だったが、
>>192が「大きすぎます等の案内を出す必要がある」と指摘したからエラーメッセージを追加したが、MAX_SAFE_INTEGER　だけエラーメッセージを追加するのはおかしいので他のメッセージも追加したら結果的にこうなっただけ
この程度のコードでライブラリを使う必要は感じないが、最近のコーダーはライブラリ使用の見極めが速いんだな

**デフォルトの名無しさん** · 2016/05/19(木) 03:19:33.36

ってか、キャストしてる時点で型がどうのではなく、型変換してるからな。
普通に、/^[1-9][0-9]*$/するのがいいんじゃねーの？入力は文字列なんだから。
どう考えても、Math.floorに文字列を渡す理由にならん。先頭か末尾に空白あるときはどうなるんだっけ？とか悩むじゃん。
integer.Parse通さないと数字にならないどころか、例外すら発生するのがまともな型のある言語。

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

>>201
JavaScriptは型違いをTypeErrorとせず、暗黙の型変換をする言語なんだから型変換で正しいんだよ

**デフォルトの名無しさん** · 2016/05/19(木) 05:59:57.75

>>202
知ってるよ…だから、型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。

**デフォルトの名無しさん** · 2016/05/19(木) 07:31:01.14

>>203
> 型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。
文脈を読めてないんじゃない？
型付き言語にこだわっていた人と>>198は別人

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

JavaScriptは型付き言語でないわけで、そこに型付きな考え方を付加させても、各々のポリシーでいかようにでもスタイルが変化するって事をわかってない感じ
また、型付き言語であっても変数に代入されるまでは型が確定されないわけで経過処理で型変換を挟んではいけないわけではない

**デフォルトの名無しさん** · 2016/05/19(木) 13:24:53.83

入力は限られてるし、取り扱いを間違っても原則ブラウザがクラッシュしたりすることはない。
それどころか不意に関数エラーが出ても、こういったイベントドリブンな場合は、何も問題なく復帰できることも多い。
最悪詰まっても、文章は読める。そこが所謂低レベル言語との違い。

**デフォルトの名無しさん** · 2016/05/19(木) 13:36:54.99

LLマンセー

**デフォルトの名無しさん** · 2016/05/19(木) 14:55:40.45

何も自慢できない男の人って可哀想(;;)

**デフォルトの名無しさん** · 2016/06/09(木) 09:39:33.79

arrow function の引数の丸括弧を省略する記法嫌いな人って多くないのかな

const fn = arg => { console.log(arg); };

const fn = (arg)=>{ console.log(arg); };

**デフォルトの名無しさん** · 2016/06/09(木) 13:20:53.39

時と場合によるだろう。
この場合は、あった方が良い

**デフォルトの名無しさん** · 2016/06/09(木) 13:43:16.42

>>209
省略記法全般が嫌い
{} の省略の方が嫌だな

しかし、このアンケートに意味があるとは思えんのだけど、ただ雑談したかっただけ
多いか少ないかなんてどうでもいいと思うが

**デフォルトの名無しさん** · 2016/06/09(木) 13:43:46.11

ただ雑談したかっただけ？

**デフォルトの名無しさん** · 2016/06/09(木) 14:51:10.11

>>209
省略できるものは原則省略したほうがいい。セミコロンも含む。
短く書けるとき、あえてそうしないというのは、
何らかの特別な意味を表す必要がなければしない方がいい。

**デフォルトの名無しさん** · 2016/06/09(木) 16:09:58.83

>>213

そういうのは、ミニファイツールでOKでしょう。
コーディング中は、原則省略すべきじゃない。
GitHubで公開するソースも省略するべきじゃない。
可読性を下げてはいけない。

省略した方が読み易いとか云う奴は、独りよがりの変態なだけ

**デフォルトの名無しさん** · 2016/06/09(木) 20:35:01.66

>>213
釣りはウザイから止めろ。
ガチで勘違いしているのなら google のコーディングルール読め。駄目な例まで挙げてある。
http://cou929.nu/data/google_javascript_style_guide/

>>209
一般にどうなのかは分からんな。
しかし所詮は慣れだろうし、世間がそう書くなら慣れるしかないのでは。
なおそのケースなら俺は function と書くが。
sortの引数のような最初から function であることが確定している部分はいいけど、
それ以外の所（何が書かれるか分からないところ）には function と書いた方が見やすいと思うから。

**デフォルトの名無しさん** · 2016/06/11(土) 16:34:28.13

>>214
いいや、無駄なものが付いてるほうが可読性が落ちる。
特にGitHubではセミコロン省略が推奨されてるでしょ。
https://github.com/feross/standard/blob/master/RULES.md#semicolons
それなのに付けろというのはそれこそ独りよがりだよ。
でも君が独りよがりだから悪いとは言わないよ。
JSは独りよがりで自由であるべきだからね。

**デフォルトの名無しさん** · 2016/06/11(土) 16:40:46.73

>>215
釣りではない。
GitHubやnpmなど、セミコロンフリーのスタイルは確立されている。
自分も様々なスタイルを試した結果、今はこれに賛同しているだけ。
ただし、この２つは同じく原則省略でも細部の取り回しが異なる上、自分もそれらとは微妙に異なる。
ルールセットの他の部分は当然違う。結構細かくいろんなスタイルが存在する。
そのどれもが考えられてるのだから悪いとかフザケてるとか思うようなことでないと思う。
それなのに人の信念というか、正義を釣り呼ばわりするのはかなり独りよがりだと思う。
でも落ち込まないで、そんな君も好きだよ。

**デフォルトの名無しさん** · 2016/06/11(土) 17:39:28.29

>>217
キモいわ。

個人が作った勝手ルールだろ。それに従いたければ勝手にしろよ。
googleの方は「こういう問題があるから、こういうルールにしました」という、極めて実用的なものだ。
俺がgoogle側のルールを妥当とするのはこの点からだ。
コーディングルールは、見やすさではなく、バグを含まないためにある。
セミコロン程度の見やすさなんて、所詮慣れでしかない。
付いている方が無駄バグが発生しにくいのなら、当然それがルールで、見にくいのなら慣れろ、という立場だ。

お前はこのスレに来るべきではない。テンプレ読めよ。
お前は3,000行のコード、書けないだろ。

**デフォルトの名無しさん** · 2016/06/11(土) 19:12:42.34

>>217
つうかおめー、マジで頭おかしいぞ。
有名どころは全部「セミコロン付けろ」だぞ。
個人レベルでの勝手ルール持ち出すとか、キチガイだと分からないか？
それともGitHubを勘違いしているか？あれは誰でもアカウントを作れる。もちろん君でも。

> JavaScriptのスタイルガイドまとめ(おすすめ4選)
> google
> jQuery JavaScript Style Guide
> Airbnb JavaScript Style Guide
> > https://github.com/airbnb/javascript (star 36,207、対して feross は 5,886)
> Node
> http://qiita.com/takeharu/items/dee0972e5f39bfd4d7c8

**デフォルトの名無しさん** · 2016/06/11(土) 19:13:01.99

> npm
> https://www.npmjs.com/package/standard
npmだけは確かに「省けるセミコロンは省け」と言っている。
ざっくり見た感じは、「JavaScriptについてよく知れば、それが出来る」ということらしい。
つまり、どういうケースでAutomaticSemicolonInsertionが動くか理解して、
常にそれを考えながらコーディングしろ、ということなのだが、
そんなことやってるからJavaScriptの連中は上達してないんだと思うけどね。

本来のプログラミングの「技能」は、言語をまたいで汎用的なものだ。
その言語でしか使えない知識は、「文法」でしかない。
俺たちはJavaScriptのおかしな文法を極めたいわけでもない。JavaScriptを使いたいだけだ。
君の論理なら、使いたいだけのために勉強を強いるのもまた「独りよがり」でしかないだろ。

不思議なのは、JavaScriptの連中にはこの主張をする輩が多い事だ。
npmが震源だったということなのか？
C++で「テンプレートを極めてから来い」
C#やJavaで「クラスライブラリを極めてから来い」
なんていう奴はいない。それはどだい無理だからだ。
だから知っている範囲でコーディングを開始していく。そして「そんな機能あったのか！」ってのも割とよくある。
JavaScriptはギリギリ極められるくらいの軽量言語ではある。
しかしだからといって、それを極めたところで益はない。せいぜいセミコロンが省けるだけだ。
そんなことに時間をかける価値なんてないだろ？
全部セミコロン付けてリントで落とし、さっさと本題に行こうというのが普通だ。

**デフォルトの名無しさん** · 2016/06/12(日) 00:32:26.03

詳細確認したが、
> セミコロンフリー (>>217)
ではないぞ。

> // ok
> ;(function () {
> window.alert('ok')
> }())
>
> // avoid
> (function () {
> window.alert('ok')
> }())
> https://github.com/feross/standard/blob/master/RULES.md#semicolons

必要な時には行頭に付けろという、一周回った発想だ。

**デフォルトの名無しさん** · 2016/06/12(日) 00:33:54.14

npmの所にある3者のうち、（全部読んではないが、videoは全部見た）
1つ目は教条的な理由、
> “They’re required because ASI is unreliable.” Seriously!?
> These rules date back to the early days of JavaScript, in the late 90s.
> They’re not new, and in my opinion there is no excuse for someone calling themselves a professional JavaScripter and not understanding statement termination.
> It is blatantly irresponsible of the thought leaders in the JavaScript community to continue to spread uncertainty rather than understanding.
> http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding
2つ目はどのみち必要だという理由、
> Even if you use semicolons at the end of every statement, some constructs parse in non-obvious ways. Regardless of your preferences in semicolon usage, you must know the rules to write JavaScript professionally.
> http://inimino.org/~inimino/blog/javascript_semicolons
3つ目は「関数には要らなくて関数式には付けろとか『初心者には』分かりにくい」ということだった。
> https://www.youtube.com/watch?v=gsfbh17Ax9I

よく見るとなるほどこのnpmのコーディングルールの作者がferossか。
ならばそれは「GitHubで確立されている」とは言わない。それは君がGitHubを勘違いしているだけだ。
GitHubはただの置き場であって、誰でも何でも置けるんだよ。プログラムである必要すらない。
とはいえnpmではある程度の評価を得ていることは事実だな。ただ明らかに主流ではないが。

セミコロン無しの有名言語はRubyとPythonだと思うが、そっち出身でなければ大人しく付けておいて、それに慣れた方がいい。
Ruby/Pythonとの相互運用なら可能性はありだが、
俺はRubyもPythonも知らないのでどちらがマシかの判断は付かない。

**デフォルトの名無しさん** · 2016/06/12(日) 05:22:59.97

>>222
大人しく付けておいて慣れたほうがいい。ね。
興味深い考え方だね。
でも自分はどんな作業にしろ常に思考し改善しようと努力する質だから。
大人しく常識に沿って手を動かすだけというのは好きじゃない。
少しでもそういう意識があればむしろ書かれているように、
Note: If you're often writing code like this, you may be trying to be too clever.
Clever short-hands are discouraged, in favor of clear and readable expressions, whenever possible.
というのに「気づく」と思う。
キモい？当たり前。
俺も散々吐き気をこらえていろいろなスタイルや概念を試してきた。
何度も行ったり来たりした。
キモいのは上等！その先に必ず改善があるのだから。
そして多くを見れば本当に「キモい」ものが何かがわかってくる。
class構文やプロトタイプ的継承術に慣れた後では
JSのデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
でも分かった。そういうのを他人に求めるのはエゴなんだと。
すまなかった。。。。。。。

**デフォルトの名無しさん** · 2016/06/12(日) 05:36:18.79

>>220
極める必要なんてない。
例えば暗黙の型変換周りと比べると非常に明快。
ただ、「括弧で始まる前に付ける」。
これさえ守ればいい。
細かいこと言えば『接続させたくない』接続可能な他の演算子の前にも付ける必要などあるが、
まずそうであることはありえない。

そして「括弧で始まる」ようなものを書くようになるのは入門終了後だから、
その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。

**デフォルトの名無しさん** · 2016/06/12(日) 05:49:08.10

>他人に求めるのはエゴ
はいこれで決着ね

**デフォルトの名無しさん** · 2016/06/12(日) 11:40:13.85

>>223
いや悪いが「キモイ」ってのは君の投稿内容のことであって、JavaScriptの記法の事ではなかった。
ここは馴れ合う場所ではない。

ただやはりそれは努力の方向を間違っていると思うよ。
先に書いたように、「文法」を覚える努力をいくらやったところでプログラミングの「技能」は上達しない。
勉強する前に鉛筆の削り方に異常にこだわるようなものだ。さっさと勉強を始めた方がいい。

> class構文やプロトタイプ的継承術に慣れた後では
> JSのデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
釣りか？JSのデフォの継承システム＝プロトタイプ的継承だが。

> その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。
「とりあえず全部セミコロンつけとけ」の方が楽だ。何も学ぶ必要はない。(JSなら余分も問題にならない)
なお、JSの場合はセミコロンは「必要な場所に無ければ挿入される」であって、「不必要」ではない。
そして return の場合は改行でいきなり終端されるとか、動作に一貫性がない点もある。
たぶんRubyやPythonは最初から「不必要」で設計されている。この点が違う。

**デフォルトの名無しさん** · 2016/06/12(日) 11:40:36.40

インターネット上で自分と同じ意見を探すのは、使い方を間違っている。
最近「ブサヨ」「パヨク」とか言われているだろ。あそこまで見事に「裸の王様」になるのかとも呆れるが、
君は彼等と同じインターネットの使い方をしている。
どんなマイナーな意見でも、世界中を探せば同意見の奴は大概見つかる。自分が世界一マイナーな確率なんてほぼゼロだから。
だから、検索でヒットしても安心したら駄目だ。それはどれくらい支持された意見なのか確認する必要がある。
大勢が採用した物には、それなりの理由がある。マイナーならばそれにも理由がある。

君にはJavaScriptの技術力もないし、
マイナーな意見をGitHubの大勢だと勘違いしてしまう程、インターネットのリテラシーもない。
もちろん何故大勢が「セミコロン付けろ」なのかも分からないだろ。
余分な苦労をせずに上達したいのなら、「普通に」色々やった方がいい。もちろんそれも含めて君の自由だが。

そしてやはり君はここに来るべきではない。邪魔でしかない。
この手の「議論以前の常識」についてグダグダ言いたくないから別スレを作ったんだ。
君は「質問スレ」でいいはずだ。彼等はこの題目なら嬉々としてレスしてくるだろうし。

**デフォルトの名無しさん** · 2016/06/12(日) 11:50:23.91

ここまで静観して見てたけどその例えはどうなのよ
Web板での政治社会的なレッテル貼りや質問スレの～行以下のコード云々の煽りはともかく
このスレでだけはまともに議論や情報交換をするものだと思っていたのに心底残念だよ

**デフォルトの名無しさん** · 2016/06/12(日) 12:18:41.79

セミコロンは付けるか付けないかではない。付けさせるか付けさせないかだ。
そう考えれば付けさせるしかないだろ。

**デフォルトの名無しさん** · 2016/06/12(日) 12:24:25.95

>>228
では出ていくなり、他スレを立てるなり、好きにすればいい。それも自由だ。
ここは言いたいことを言い合う場所であって、言って欲しいことを言ってもらえる場所ではない。

どこについて怒っているのか若干謎だが、
「ブサヨ」「パヨク」については適切な例えだと思うぞ。実際そうだし。
ただ彼等について嘲笑するだけなのは、それもまた駄目なんだよ。
自分もそこに陥ってしまう危険性に気づき、他山の石としなければならない。
実際、彼もその罠に嵌っているわけだし。

マイナーな状態で旗印があれば信者はそこに飛びつく。
そして周りが自分と同じ意見であることに安心してしまうのだが、それでは駄目なんだ。
セミコロン無し派がnpmに集結しているのは正直驚きだった。だから詳細を確認した。
結果、「宗教」だった。対してgoogle/jQuery/Node/Airbnbは「実利」だ。俺はノータイムで「実利」を取る。
とはいえ、いずれにしても「宗教」の時点で議論する意味はない。
どうあがいても平行線だからね。

だから結局好きにするしかないのだが、セミコロン付ける派にも「宗教」の奴はいるはずで、
人口が C/C++/Java >> Ruby/Python な以上、「宗教」としてもひっくり返らない。
だから変にこだわるのではなく、「セミコロンあり」に慣れるしかないだろ、というのが至極妥当な見解だと思うが。

**デフォルトの名無しさん** · 2016/06/12(日) 12:26:16.47

>>228
ここで議論したことあるけど、高確率で煽る方向に絡まれるから有意義な議論は期待できないと思うよ
議論中に軌道修正しようとしたけど、ほとんどが無駄だった

**デフォルトの名無しさん** · 2016/06/12(日) 12:33:31.15

>>229
そうなんだけど、セミコロン無し派も結構ガチなんだよ。
リンターも整形ツールも既に提供している。
あのferossって奴もGitHubの垢見る限りそこそこ大物だ。

ただ正直、そこまでこだわる理由もよくわからんのだが、、、

**224** · 2016/06/12(日) 16:06:44.39

>>227
俺はここはJSを愛する者達のスレ、と認識していた。
今は亡きECMAスレの面影を重ねているのかもしれない。
要するに、より良いJSを目指す者質の意見だ。
ただの常識とやらにそった意見の飛ばし合いならばそれこそそこらの質問スレですればいい。
こういう議論をするためこそにこのスレが有るのだし、
現にこういう議論が出て初めてスレが伸びたんだからそういうことに違いないだろう。
ともかく、こういう議論をすること自体は良い。としてもらいたい。

>>229
彼に少しでも良いJSを目指したいという精神が感じられなければ、またこういうスレでなければ俺も「あえて」付けるなとは言わない。
この場所、このタイミングで質問した彼には真実に繋がるヒントを伝え、そこへ目指して欲しかった。

>>230
>>「慣れるしかない」
どうして？いや、仮に「セミコロンを原則付けること」に慣れる必要があるとしても、
「セミコロンを原則付けないこと」にも慣れてはいけない理由なんてないし、
そっちを普段自分の中でメインで使って良くない理由なんてないよな。

>>232
俺がこだわっているのは、「セミコロンを付けないほうがいい」ということよりもむしろ、
そういうことを教えたり教わったり考えたり、もっと自由な研究をしようよということだな。
た　だ　し、『プログラマー』『スクリプター』『JSer』になりたいのならね。
そうでないのならどうでもいいが、俺はそうなってほしい、JSを愛して欲しいと考えるからこうした立場をとっている。
JSを教えるとき、JSって、スクリプト言語って、プログラミングって楽しいんだよ、深いんだよ、広いんだよ
ということを感じてほしくはないかい？俺は欲しい。
一緒にJSを味わい尽くし、発展に協力してもらい、共に夢を見る関係になりたい。
そう思うことはそんなに変かな。
このスレでは許されると思ったんだけどね。寂しい。。

**224** · 2016/06/12(日) 19:04:38.68

あー、それとここまでの流れをちゃんと見てみたら混乱を招いてるようなので
一つ断っておきたいんだが、俺はバランスタイプなんだ。
俺が「セミコロンを付けないほうがいい」などと言ってるのは、
あくまで彼に対するレスが偏り過ぎないよう、不足分を埋める立場になっただけで、
その瞬間ではあくまで彼のためだけの、彼の方向に向いたレスでしかない。
他のレスとは補完関係であって、互いに影響を及ぼしたり対立したりするつもりはない。

もし他の人が「セミコロンを付けないほうがいい」といったならば、
俺は逆の立場から言っていた。
あくまで俺の目的は、広く深い心と知見と情熱を持った『JSer』育成にあるからだ。
何か１つのそれっぽい答えを貰うだけで満足してほしくはない。
いろんな案を受け入れ、自ら試行錯誤してより良いJSを追求していって欲しい。

**デフォルトの名無しさん** · 2016/06/12(日) 23:59:15.39

自転車置き場の議論てやつだな
あほだな

**デフォルトの名無しさん** · 2016/06/13(月) 00:25:03.07

>>235
ほう、名詞があるんだね。
色々考えたんだけど、JavaScriptの連中が上達してない原因は多分そこだと思うんだよ。

C初心者「for文、while文、if文…」
JavaScript初心者「for文、while文、if文…」

C初心者「ポインタ…」
JavaScript初心者「セミコロンはどこに打つべきか議論しよう(ｷﾘｯ」

C初心者「ポインタ…ポインタ…構造体…」
JavaScript初心者「暗黙変換の活用について(ｷﾘｯ」

多分、本質的でないところにトラップされてるんだ。
Cはこの点、寄り道無しで初ボスかつラスボスのポインタがいきなり出てきて勇者は死ぬ。
そして何度も復活の呪文を唱えつつ、そこを抜ければいきなり中級者になってる。
JavaScriptの連中は完全にここで空回りしてしまってる。
セミコロンを打つ場所なんてマジでどうでもいいのに、さも重要なことのように言うのは詐欺だよな。

**デフォルトの名無しさん** · 2016/06/13(月) 06:36:45.25

>>236
実際には、セミコロンを打つ位置ではなくて、なぜセミコロンが省略でき、その場所では省略してはいけないのかが問題なんだけど、題目的にしか議論してないからな。
ポインタだって、参照と実体とかにフォーカスした方がいいんだろうけど、その辺スルーだし。

**デフォルトの名無しさん** · 2016/06/14(火) 10:56:42.92

>>236
一番重要で本質的なことは、
長く複雑なコードをいかにスマートに書けるか、
いかに問題を短く簡潔なコードで早く書けるか、
ってことだと思うよ。
各機能がどうのこうのは、それこそどうでも良いというか、
基礎という意味では重大だけれど、レベルが低いことだと思う。

セミコロンを打つ場所なんてマジでどうでもいいというのは、
それは初心者にとってそれよりも先にやるべきことがあるからその通り。
しかし中級者以降生産性やコードの質を上げていこうと思えば
この手の物事の重要性は増していき、最後には信念やら宗教やらと言われる問題に行き着くと思うよ。

ここは既習者スレなんだから、そういうことこそを話し合うべきだと思うけどな。

そして空回りしているというのは、ある見方ではそうだと思う。
JSは仕様の内も外も具体的な実装について殆ど意識されていないからね。
でもそれは逆に、具体的な実装に囚われず概念を学べると言えると思う。
その概念を習得すれば、例えば他言語に移ったとしても柔軟に対応できる。

他にもJSはマルチパラダイムと強く意識されて作られたわけではないが、その真似事ができる。
むしろJSこそ最も様々なプログラミングにおける本質的な物事を学べる言語だと思う。

**デフォルトの名無しさん** · 2016/06/14(火) 18:26:48.94

検索用にセミコロンを 2 個3 個続けるのもありかな

**デフォルトの名無しさん** · 2016/06/15(水) 01:26:31.98

検索用にセミコロンを 2 個3 個続けるのもあり
と君が判断したのなら君の中ではありなんだろう

**デフォルトの名無しさん** · 2016/06/15(水) 20:32:12.77

マンセーが異様に多いのもJavaScripterのおかしな所だよな

**デフォルトの名無しさん** · 2016/06/16(木) 07:55:44.05

そうか？
むしろスクリプト言語の中じゃ代表コミュニティもないし、そういうのは少ないほうだと思うが。

**デフォルトの名無しさん** · 2016/06/16(木) 08:00:04.44

利用人口ぱねえからな。変なの目にする機会も多かろう。

**デフォルトの名無しさん** · 2016/06/16(木) 15:16:35.80

他人を理解できないってのは悲しいね

**デフォルトの名無しさん** · 2016/06/18(土) 01:00:30.57

>>243
人数自体はそんなに大したことはない。
おかしな奴の割合が異常に高いんだよ。
Webがホームということもあり、未熟な奴が平気で情報発信()している感もあるが。
http://www.tiobe.com/tiobe_index
http://spectrum.ieee.org/computing/software/the-2015-top-ten-programming-languages
http://pypl.github.io/PYPL.html

**デフォルトの名無しさん** · 2016/06/18(土) 05:23:04.56

マンセーしたら未熟者扱い？
エキスパートな俺様は苦しんでるのに許せない間違っているってことだろうか
それとも辛い経験豊富で批判的な俺様カッケーって勘違いアピール？
傍から見るとひねくれ者の妬みにしか見えないが……

**デフォルトの名無しさん** · 2016/06/18(土) 14:06:50.57

観測範囲の問題
JavaScriptに限らず、おかしな人はどこにでもいる
このスレの>>1は相当な変わり者だったようだが

**デフォルトの名無しさん** · 2016/06/19(日) 04:58:43.41

おかしくない人って何よ

**デフォルトの名無しさん** · 2016/06/19(日) 10:12:00.06

>>245
Google で検索されたキーワード辺りで指標作った方が良さげな気がする。

**デフォルトの名無しさん** · 2016/06/19(日) 12:28:35.73

ここは>>1を含めて俺様主義の人が常駐してるのでまともな意見交換は出来んよ
始めは冷静でも、少し意見の食い違う人が現れただけでただの「主張の押しつけ合い」に発展する
意見交換するなら「そんな考え方もあるのか」ぐらいに自分の立場を引いて見つめる客観性が必要だが、彼は否定にかかるだけで相手をやりこめないと満足しないからな

**デフォルトの名無しさん** · 2016/06/19(日) 15:16:34.64

俺もお前も仙人や神様じゃなく凡人なのだから、性質に割り振れる度合いは限られてる。
結局思考停止の傲慢くんも、視野無限の優柔不断くんも、同じくらい悪い議論しかできない。
その中間であっても、両者の悪いところを半々持つので、同じくらい悪い議論しかできない。
つまり無理難題夢物語ということ。「こんな議論もあるのか」ぐらい許容的になってもよかでは？