16/05/14 13:46:57.24 Jg6FEyPA.net
> Webは中央政権的でない（なくなった）から全てをひとまとめにしてバージョン付けはできない。
これはそちらの認識が間違っている。
そもそも、仕様を策定するのは「困るから」であって、「支配する」為ではない。
元々W3Cがその位置にいたのだが、官僚的だったのか、とにかく仕様の決定が遅すぎた。
だから無視するのが通例になってしまっているが、本来はW3Cが機能していればよかっただけの話だ。
ただ結果を見ている限り、clientHeight/innerHeight等、
名前を決めればいいだけの部分でさえすり合わせ出来ていない点、
あるいはJavaScriptと名乗れずJScriptとなっている点等からしても、
（どちらが仕掛けたかはよく分からないが）何らかの政治的思惑が絡まっており、
W3Cは「使えない」として見切りをつけられているように見える。
（見切りをつけたこと自体は正しいが、それによって我々が不便をこうむっているのはご承知の通り）
136:デフォルトの名無しさん
16/05/14 13:48:07.29 Jg6FEyPA.net
> 中央政権的なFlash等プラグインの死
以下を読んだ。
> URLﾘﾝｸ(uxmilk.jp)
まあ俺も筆者と同意、Flashは死ぬべくして死んだだけ、
ジョブスが引導を渡した形になったのは、ジョブスに先見の明があっただけ、と思える。
実際、今Flashが欲しいって思うことは無いだろ？要らなくなったんだよ。
だから君の
> Webは中央政権的でない
というところが大前提として間違っている。
そもそも、何であっても「中央政権的」ではないんだよ。それが資本主義だから。
例えば、iPhoneが中央政権的であるとしよう。
ではiPhoneがその機能を「搭載」あるいは「削除」したら、他が「必ず」付いてくるか？
答えはNoだ。Flashが必要なら他サイトは対応し続けるだろうし、iPhone側も搭載を余儀なくされる。
例えば初期のiPhoneは「コピペ」機能が無かった。これはジョブスが「不要」と判断したかららしいが、
さすがにこれは3代目くらいで「復活」した。（これについてはなぜいらないと思ったのか謎）
Windows8はスタートボタンを「廃止」したが、誰も望んでいないこの変更は修正を余儀なくされた。
かつてRIMMという先進的DRAMがあったのだが、特許料を取るだけのものだと判明したため、
各社は旧来のDDRをDDR2/3/4と進化させるほうを選択し、RIMMは死んだ。
何かを中央政権的に仕掛けることは出来るが、それを追認するかどうかは市場が決める。
結果的に、無理な仕掛けは頓挫するようになっている。これは資本主義のいいところだよ。
君の世界観が中央政権的なものを肯定するのは、
一般に中央政権的なことが出来る規模のトップにいる奴はかなり優秀で、
そいつらのやったことが正しくて追認されることが比較的多いからだよ。
ただし上記のように、探せば結構間抜けなこともやっている。
137:デフォルトの名無しさん
16/05/14 13:49:00.26 Jg6FEyPA.net
だから、それが大多数の人にとって正解と思えるのなら、自然と
> じゃあもう低レベルなAPI群を定義して、もっとオープンに仕様を発展できるようにしよう。
ということになっていく。それは君や俺がどう思おうが関係ない。
ただ、そうなっていないのなら、それはそう認識されてないということだよ。
つまり君の認識が間違っているということ。
asm.jsもServeceWorkerももう数年になるが、これらは君的には普及したと思えるのかい？
あるいは、これらの流れを受けて、低レベルAPIを規定していくことが主流になったと思えるのかい？
俺にはそうは見えないけど。
138:デフォルトの名無しさん
16/05/14 13:49:22.05 8701OXOx.net
将来においても絶対に変わることがなくて、
ブラウザの実装者の負担にならない最低限の共通の機能をもったAPI
そしてその共通APIを使ってより便利なことをするライブラリ。
この2つを「標準化」するべきなんだよ。
今現在は、最低限のAPI部分しか標準化されてないから
jQueryやlodashなどがでてきてしまっている。
最低限の機能だけじゃ開発は楽にならないので、
他の別の何かは絶対に必要になる。
139:デフォルトの名無しさん
16/05/14 13:49:51.20 Jg6FEyPA.net
> よりオープンなそれこそ誰でもGithubに書いて主張できるような仕様形態に「自然となっていった」。
これは事実としてそうなっているね。
つまり大多数の人にとって、これが「現状一番マシなやり方」と認識されているということ。
ただし、
> バージョニングの弊害の反省
これはjQueryか？
一般的にバージョニングで問題が発生するのは使い方が悪いだけ。
つまり、「仕様」に関わってはいけないレベルの馬鹿な奴らがバージョンを規定するからだよ。
そして必要な機能を「中央政権的」に落としたりするから混乱する。
あるいは変更の必然性が無い（延期できる）部分をバージョンを変えたからといって無駄に変更してみたり。
バージョニングで成功している例は、例えばWindowsだよ。
外面バージョンは、95, 98, Me, 2000, XP, Vista, 7, 8, 10 となっている。
これらまとめて全部 Windows という名詞しかなく、
明示的に分離することが出来なかったら、会話するのに困るだろ。(Linuxがそれに近い状態）
正しくバージョニングが出来ない連中ばかりだからといって、
バージョン自体をつけないのはさすがに間違いだよ。
実際、ES5,6,7, HTML4,5, CSS3,4ってのがバージョンだし、バージョンが付いてない案件はさすがに無いと思うが。
（バージョンが廃止された案件は無いはず。機能していない案件は多々あるとしても）
そして「このブラウザでは、HTML5, ES5, CSS3 まで対応しています」と言い切るためのもの。
140:デフォルトの名無しさん
16/05/14 13:50:45.96 Jg6FEyPA.net
ところで、
> Bluetooth機能
これは何？と思って調べたら、本当にあるんだな。
> URLﾘﾝｸ(developer.mozilla.org)
仕様としてはまあ妥当だな。
正直、bluetoothまでWeb側で面倒を見る必要があるとは思えないが、
OSのシステムコールを直接やらせることは出来ないという縛りによって、
OSのシステムコールの再発明を迫られるという間抜けな事態に陥っている。
とはいえ、これについては今後とも再発明し続けるという解しか思いつかないな。
IEEE側の仕様を上手いこと流用する手はあるはずだが、あちらは低レベル過ぎるだろうし。
141:デフォルトの名無しさん
16/05/14 16:17:29.52 ciGNYqZA.net
だいぶ意見の摺り合わせがなされた。殆ど言葉の定義的なことやニュアンスの行き違いで
多分経験と立場からくる「常識」などの差を考えれば、根本的な部分の意見の出し方の相違はあまりないと思う。
もうこれ以上は無理だろうけど、明らかに違う部分と、自分の中で強い意見を持ってる部分だけ言っとく。
まずバージョニングについて。
もちろんバージョンが付いてる仕様（ほぼW3Cが中心で策定）も未だ多くあるが、Living Standard版（ほぼW3C以外が中心で策定）の仕様も多くある
HTMLのように両方ある場合、『ブラウザベンダーが見るのは、LS版の方』で、こっちURLﾘﾝｸ(html.spec.whatwg.org)
（ここの1.6までを読めば多少感覚がわかると思う）
バージョンが付いてる方は、バージョンが付いていないと困ること（例えば製品の対応状況の表明、例えばある時期においての仕様参照）のために、
LS版の方から重要な部分を定期的に抜き出してまとめてるだけのものであって、実際我々開発者にとっては意味のないと言っていいくらいのもの。
まあバージョン＝悪いとは言わない。仕様開発においてバージョンにとらわれ過ぎることの弊害というべきか。
そしてLS版はある意味で更新日付がバージョンとも言える。ようは異質な存在というより、もっと回転を早くしていきましょう的なものとも言える。
142:デフォルトの名無しさん
16/05/14 16:20:23.84 ciGNYqZA.net
そしてJSらしさについて
そもそもJSらしさとは何なのか？例えばクラスっぽいものを作ろうとした時、
functionと.prototypeを使うのがそうなのか？
それでもって継承っぽいものを実現したいときは、ハックに近い方法で言語の底のプロトタイプ性に干渉し為すのがJSらしいということなのか？
それとも今となってはclass構文と、extendsで実現するのが素直にJSらしいということなのだろうか？
自分はというと、どっちも使う。さらに、__proto__を使ったピュアなプロトタイプベースでクラスシステムを作ったり、mixinもやる。
そしてその全てがJSらしいと思っている。汚い部分も、何でもかんでもやろとする部分もJSらしさだ。
型付配列だってそう。JSに存在しているのだから、それを活用することは当然JSらしいと思っている。
自分はJSに関しては、仕様、策定プロセス、実装（特にV8）も含めて愛していて、自分にとってJSとはその世界全体だ。
いい加減に書けるのもJSだが、「こう書けば速くなります」と言った書き方もJSだと思う。
なぜならエンジンはJS(ES)仕様を実装しているわけだが、実装されたものがJSとも言えるからだ。
昨今標準仕様として策定が完了するためには、最低２つのメジャーなエンジンに実装されることが必要とされているが、
逆に言えば複数のエンジンがきちんとした意思を持って実装したものは仕様と近しいと思っている。
また重要なこととして、各エンジンの最適化は、なにも適当に出来そうなニッチなケースからしているわけではなくて、
世間で使われているコードが速くなるような最適化がなされているのだ。
つまり何がいいたいかというと、曖昧なJSにおいて、比較的きちっと最適化パターンに沿って書くのは、
テクニカルというより、『お行儀が良い』行為なのだ。
そして、asm.jsについても似たことが言える。TypedArrayを使うのは『良いアルゴリズム』だし、
asm.jsに沿って書くからといって、別にJS道を外れるというわけでもないのだ。
人それぞれ好きなように書けるのがJSだ、と考えてる。
143:デフォルトの名無しさん
16/05/14 16:39:37.40 ciGNYqZA.net
>>132
チョット違うな
「ちゃんと」ってのは「ちゃんと」だ。
ただ、「（そういう）ニッチなケース」における、「ちゃんと」だってだけ。
ただ自分がニッチなケースをわざわざ挙げたわけではなく、必然的にそこに行き着くということ。『必然』
「言語」で対比して話しているようだったからDOM周りの外部APIを活用するような、Webにおいて普通のものついては除いて考えざるを得なかった。
ただ1+1を何億回やるみたいなのの延長のマイクロベンチで語ってもあまり仕方ないと思った。
先方がN-Bodyを例に出していたので先にそちらにも触れたが、もうちょい大きな実用物でもそう言えるということを書いた。
そしてそのもうちょい大きな計算主体な実用物ってのは、自分が思い浮かんで良く作ってる中だと、
ゲームの先読みAIか、エンコーダ的なものかしか思い浮かばなかった。
だから前者のようなものでは1/2、後者ではまだSIMDとパラレリズムの実装が不十分な段階だから、もう1/2にはなるよと説明した。
別にそれはJSで書かなくてもいいと言われれば、勿論そのとおり。
でもJSで書くとなったとき、これらをJSで書こうとする微変態が「ちゃんと」書くとは、
当然最低でもボトルネック部分はasm.jsスタイル、そしてSIMD、SAB、AtomicsみたいなAPIも使いたいと思うだろう
（実際に対象の互換性を考えて使えないこともあるとかはおいといてね）という前提や思考の流れで書いた。
144:デフォルトの名無しさん
16/05/14 17:31:31.31 ciGNYqZA.net
ここまでの流れ、ちょっと狐につままれているような感じだ。
自分としては歴史や試した経験事実に沿って、淡々とお話した部分が多い。
別にこの宇宙において何が善悪かを語ったつもりもなく、一例を挙げたりしながら部分部分に対して必然的な事柄を語っただけだ。
だからバザール型云々の話も意図的にスルーしている。
本来は何が正しいのか、歴史のどこが間違っていたのか、を語りたいのではなく、
今はどういう状況で、それに沿って今からどういう心構えでいればいいのかを把握し、
一緒にWebを良くしていこうねということがしたかったからだ。
もしかすると例えば自分はその低レベルAPIが大成功すると考えてると思われてるのかもしれないが、べつにそうは思っていない。
策定に関しても、難しさは高レベルAPIと同じくらいだろう、と書いたように別に現状と大きく変わるとは思っていない。
ただ、そーゆーじだいなのよー、いーものつくってほしーね、ってだけ。
まあ、そういうわけなので、そもそもダメ、とか言うのは今回の話においてタブー視していた。
そもそもダメ、それも代わりにこっちの方がいいという案も出してくれてはいるものの、過ぎたことだったり、現実そうはならないことばかりだった。
今の流れに沿った上で、こういう風に改善していく道があるんじゃないかと具体的で現実的に示して欲しかった。
（現実的というのは、今からメーリングリストで発言すれば多少は風向きを変えられそうなくらいな意見をイメージしている）
まあできれば、APIレベルの改善点を挙げて欲しかった。
こういうAPIが良いんじゃないか、だから抽象的一般的にこういうことが言えるんじゃないか、
だから今のWebのこの流れは間違ってるんじゃないか、とね。
そうじゃないと、Webはそもそもがダメ、それを素直に直すのは無理、じゃあWeb捨ててネイティブ行くか！ネイティブ最高！
くらいしか考える事、言うこと無いよね、って思った。
145:デフォルトの名無しさん
16/05/14 19:38:06.23 8701OXOx.net
三行でまとめろ
146:デフォルトの名無しさん
16/05/14 19:41:36.67 8701OXOx.net
> そうじゃないと、Webはそもそもがダメ、それを素直に直すのは無理、じゃあWeb捨ててネイティブ行くか！ネイティブ最高！
> くらいしか考える事、言うこと無いよね、って思った。
ウェブ技術でネイティブ開発すれば良い。
そうすればネイティブのものをウェブに以降することもし易いし
その逆も簡単になる。
今はネイティブの方が機能も多く速度が早いが、その問題も
ハードウェアとソフトウェアの進化によって次第に解決しつつある。
JavaScriptに新しいAPIが生まれているのは、ネイティブにしかない機能を無くすためだし、
asm.jsとかも速度を早くするため。
最終的にウェブ技術さえあればどちらの開発もできるようになる。
その時ネイティブアプリの終焉が訪れる。
147:デフォルトの名無しさん
16/05/14 22:08:17.97 Jg6FEyPA.net
>>141
1.6まで読んだ。なるほどWHATWG側の見解は分かった。
しかし、ある意味ありがちな展開だ。
仕様を決めている奴は仕様を決めるのが目的で、使うためではないからな。（手段の目的化）
これは決裂して当然、とはいえもうちょっとマシな展開は無かったのかとも思うが。
そしてECMAscriptの仕様書が他言語と比べて異様な理由も理解した。
LS版が日付＝バージョンなのはそれでいいが、
LSってのは「永遠に追いつかない目標仕様」であることを意味する。
実際そうなのかもしれないが。
本来は「仕様」がまずあって、それに沿って各所が部品を用意し、一気に組み上げるものだ。
プレハブの家とかいい例だ。
H264だって、仕様が確定してからでないとハードウェアデコーダは実装できない。
（仕様が少しでも変わるとゴミになる恐れがあるから）
LSってのはWebみたいに、いつでもダウンロードできて最新版が提供できるという前提でしか使えない。
LSでいけること自体がWebの強みかもしれんね。
148:デフォルトの名無しさん
16/05/14 22:09:49.21 Jg6FEyPA.net
> JSらしさ
ユルい所だよ。だから君の理解も間違いではない。
言語を比較するのなら、便利機能はどんどん追加されるから、裸の状態で比較した方がいい。
JSについては、型無し、動的確保、全ての関数にクロージャ、
お手軽匿名関数、正規表現、といったところだろう。（なお全て既存でありJSの発明ではない）
これらはCには無い。だからこれらを活用したいのならCよりJSということになる。
一方Cなら、ポインタ、最高速のメモリアクセス、ほぼアセンブラの低レベル記述となる。
だからメモリアクセスで勝負が決まったり、あるいはゴリゴリにチューニングしたいのなら、それはC向きだ。
例えばあるDOMのクリック回数をカウントしたいとして、JSなら
var count = 0;
dom.onclick = funciton(){count++;};
で終わりだ。一方、Cなら、
1. グローバルに配列またはハッシュを用意し、（遠くに記述される）
2. 各DOMに通し番号またはハッシュキーを用意し、（管理項目が増える）
上記と同様のコードとなる。
つまり、同じことを実現するのに、考えないといけないことが増える。要するに、面倒なんだよ。
JS含めてLL言語に求められるのは、チャキチャキ書いてサクッと実行、そして結果を得ることだ。
デバッグ時間も含めて結果を得るまでの最速が求められる。実行時の最高性能ではない。
だからお手軽に結果を得たければLLで、実行時の性能が第一ならCで書けということになる。
149:デフォルトの名無しさん
16/05/14 22:10:30.57 Jg6FEyPA.net
JSの特徴はユルさだ。だから君みたいに好きなように混ぜこぜで書くのならそれはJS向きだ。
ただ、TypedArray「しか」使う気が無く、またそれがそのアプリにとって重要なら、それはC向き案件だ。
それはメモリアクセス速度が重要だということだから。
N-bodyにこだわる必要は無くて、他のベンチでもおおむね同じだ。
「素のJS」を「素のC」と比べた場合、普通のコードなら5倍程度遅いということなんだよ。
当たり前だが添字範囲チェックはあるし、ハッシュキーも引くし、2重ポインタな訳だから、メモリアクセスは遅い。
TypedArrayでもこれらは変わらない。あれはこれ以前の型チェックが抜かれただけだから。
この状態で、5倍は見過ごせないというのなら、それはCで書くべきだし、
5倍程度で済むんだったら上等、それならイージーにやりたいと思うのならJSということだよ。
スクリプト言語で5倍程度なら、それは異様なほど速いので、俺は十分満足している。
TypedArrayは固定長配列だろ。それはユルさをひとつ消してしまう。
例えば、FIFOキューを作るとして、可変長なら shift(), push() だけで長さのことを考える必要もない。
それが固定長だと考える必要が出てくる。あふれないように追加のコードも必要だ。
もちろん固定長としてしか使わないのならTypedArrayでもいいし、
逆に固定長であることをTypedArrayで明記するというコーディングルールもありだろう。
しかし、こんなところを気にする奴が使うべき言語では無いんだよ。元々ね。それがLLというものだ。
150:デフォルトの名無しさん
16/05/14 22:12:06.50 Jg6FEyPA.net
多分な、Web系の奴らが勘違いしているのは、「Webは特別だ」と思っていることなんだよ。君も若干そんな感じ。
ただ、Webは特に難しいわけでもなく、移り変わりが激しいわけでもなく、また逆に、言われているほど馬鹿でもない。
関わっている普通の人たちが普通にがんばってきた結果が今であり、それはどの時代も大して変わらない。
> APIレベルの改善点
Bluetoothはあんなもんだろう。Promiseを返すのがいいのかは若干疑問だが。
DOMみたいにgetterが設定されまくったオブジェクトを返すほうが親和性があると思う。
AppCacheは要らないのなら廃止すべき。少なくとも「10年後に廃止する」というアナウンスを出すだけでもぜんぜん違う。
WebSQLも廃止するのなら廃止で、IndexedDBに統合するのなら廃止予定をアナウンスすべきだろう。
これらも放置すればブラウザの足を引っ張ることになる。廃止は10年後でいいから、その種まきを今やるべきだ。
asm.jsは基本的に意味の無い演算をすることになっていて、それで型情報を補完しているだろ。
だったら実演算部分に突っ込むのではなくて、コメントでもよかったんだよ。例えば、
function someFunc(start) {
start = start | 0;
ではなくて、
function someFunc(start) { // "use asm: int32 start"
とか。//で始まった一行コメントの最初に "use asm:がある場合に有効となる。
これだとasm.js非対応時に速度が落ちるという間抜けな事態は発生しない。
ただしコメントがバグっている場合は asm.js 対応環境でのみ動作しないということが発生する。（非対応環境では動作）
しかしこのコメントをつける奴らは当然対応環境でデバッグするのだから、これでいい。
151:デフォルトの名無しさん
16/05/14 22:13:45.30 Jg6FEyPA.net
XHRは304が見えるようにしたほうがいい。
XHLHttpRequest.canSee304 = true で status に 304 が見えるみたいなのでいい。もちろんデフォはfalseで。
あとリクエストの優先順位付けが出来た方がいい。
大量にXHRを発行するとブラウザ側の<img>レンダリングと取り合いになって、どちらかが待たされる。
優先XHR > 画面内img > 基本XHR > 画面外img > 劣後XHR
で3レベルあれば十分だと思うが、これはもう少し検討した方がいい。
今はchromeだと「先にリクエスト打ったもの勝ち」になっている。
DOMはレンダリングを一時停止するAPIがあったほうがいい。
DocumentFragmentはひとかたまりでしか使えない。
ばらばらの場所に一度に大量挿入するときにレンダリングをとめる手段が無い。
具体的に言えば、今画面に表示されているDOMをソートしなおすときとかに使う。
Array.createはやっぱり欲しいときがある。
ぱっと思いつくのはこんな感じか。
君の手柄にしてくれていいからよろしく頼むわ。
ところで君はNodeをコンソールでも使っているかもしれないようだが、デバッグ環境はどうなっている？
俺は>>122のとおりWSH+VSには失敗している。
NodeがChromeDevToolsでデバッグできるのならそれも相当魅力的なので。
152:デフォルトの名無しさん
16/05/14 22:17:11.45 8701OXOx.net
>>150
> 多分な、Web系の奴らが勘違いしているのは、「Webは特別だ」と思っていることなんだよ。君も若干そんな感じ。
Web系じゃないやつが勘違いしているのは、
「Web系の奴らがWebは特別だと思っている」はずだと
思っていることだよ。
誰も特別だと思っちゃいない。
お前には特別に見えるのか？
ならお前が特別だと思ってるんだろ。
153:144
16/05/15 05:38:37.51 79V1eiQO.net
>>146-
まあAppCacheは（一応JSへのAPIもあるがそんなに使われていない）
あくまでキャッシュなのでいきなり削除しても問題になることが少なく
特例的に極めて廃止しやすい方だ。（廃止される）
他のAPIも、LSが広まりだしてから非推奨を設定しやすくなった。
しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
開発者やそのための解説情報作者のモラルを高めないことには難しい。
とは言え、１０年も経てば流石にどんな仕様でも削除出来ると思うよ。
ただ、EWMの夢物語でさえ東京オリンピックのころかなというイメージだ。
１０年は自分にとってWebにおいて永遠と等しいように感じる。
154:デフォルトの名無しさん
16/05/15 09:04:33.00 u/cc/woI.net
>>153
> １０年は自分にとってWebにおいて永遠と等しいように感じる。
これでいいんだよ。逆に有限で廃止すると混乱する。
> １０年も経てば流石にどんな仕様でも削除出来ると思うよ。
どんな糞仕様であっても放置しているだけでは削除できない。
typeof(null) が object なのを削除できてないだろ？
あるいはthisがグローバルになるという糞仕様も削除出来てないだろ。
この2つなんて、ただのバグの温床であって、活用できるものではない。
ではデフォで"use strict"にできているかというと、これも出来てないだろ。
そういうものなんだよ。
Webの仕様で、ただの案ではなく、完全に「正式仕様」として認識されたもので、
「正式に廃止」されたものがあるかい？
上記を見る限り、使われなくなったものは多々あっても、「正式に廃止」されたものは無いんだと思うよ。
> しかし、ブラウザがその実装を取りやめるのは、各ブラウザが収集している
> ユーザーが閲覧しているページでのAPIの利用頻度が実際にほぼ無視できるレベルまで落ちた時だから
まあこれは一概には言えないけどね。chromeはJavaを切ったろ。無視できるレベルではなかったと思うよ。
実際に、俺は偶に遭遇するしね。
これも「正式に廃止」したのではなく、勝手にサポートを止めただけだ。
事実上の廃止勧告であったとしても、仕様から「正式に廃止」することは無いのだと思うよ。
本来、仕様策定とは、こういった混乱を防ぐためのものだ。W3Cは全く機能していない。
この点については、
>>131
> （昔的な）標準機構（形・影は薄れてきてる）はこれから何をするのがよいのか。
WHATWGは新仕様の採用には積極的なのだから、もうそっちは完全に任せて、
W3Cは旧仕様の削除に専念するのもありだと思うよ。
後者は要するに利害関係者間の調整であって、WHATWGの連中がやりたがる仕事ではないし、
本来の「仕様策定」側の仕事でもあるから。
155:デフォルトの名無しさん
16/05/15 12:44:09.17 mCzE/lrH.net
何で削除出来てないかって、単純に
破壊的仕様変更は許さないだけでしょ。
言語仕様を変えるのもまずありえないけど、デフォルトを変えるって実運用では禁じ手じゃん。
だから、これはvいくつですよ、って宣言書いて、非対応であればハネる仕組みを充実させるしかないし、ポリフィルが要らなくなることは無い。
156:デフォルトの名無しさん
16/05/15 13:47:01.97 e+kzQGE7.net
ブラウザのJavaScriptの特殊性を分かってないんじゃないだろうか？
開発した時のJavaScript実行環境と
違うバージョンの実行環境で動かすことだってあるのが
ブラウザのJavaScriptなんだが？
実行環境は互換性を保っていなければいけない。
当たり前の話なんだがな。
コンパイル言語で言えば、ある機械語の動作を
変えてしまうってことだよ。
157:144
16/05/15 16:58:58.26 79V1eiQO.net
>>151,154
昔は知らないが今のバージョンのXHRは試したが304が最初から見えるはずだ。
優先度については自分もこの間も悩んだばかりだ。
XHRの進化は終わっているが、Fetchの方などでそこの部分は議論されているので見込みはあるかもしれない。
Fetchでは一応今のところリクエストには優先度というパラメータがある。（ユーザーエージェントが決める）
というとこまで決まっている。
まあ、みかけ上帯域制限するだけならStreamAPI使えば今でも出来るんだが、
帯域制限することも考えたAPIでないから、このAPI上でストリームを絞ったところで
実際ブラウザやOSがそれに従うという保証がないのが残念なところ。
DOMの一部分のレンダリングを止めるというのはちょっと難しいかも知れないが、
一旦スタイル指定で隠すというのが今のブラウザに対するそう言ったメッセージで、
そうしておくと無駄な処理は省略してくれる。
もしくは、DOM及びそれにアクセスするJSのプロセスを分けるという試みが為されているので
その延長上で期待するような状態が作れるかもしれない。
そして機能の正式な廃止だが、HTML5以前は独自実装およびデファクト仕様の山で、
HTML5になってから多少は整理したが未だ漏れてるものも数多くあるので、
廃止されるとなっても、それは機能の廃止というより独自実装の取りやめ、標準への追従に見えるということ。
実際にはshowModalDialogとかそこそこメジャーでも各ベンダーが一生懸命廃止させた仕様は幾つもあるし、
人知れず消えてったマイナーな仕様、挙動は沢山ある。
158:デフォルトの名無しさん
16/05/15 17:01:58.55 79V1eiQO.net
>>154
'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
typeof nullの挙動は２年前治そうという案の盛り上がりが頂点に達したのだが互換性のために断念した。
が、将来的な演算子オーバーロードの仕様が入ると共に直す策を入れようと言う案は出てる。
もしくは、V8が画策している型付厳格JSの方向性が成ればそちらでも更生は可能。
でも自分としては、動的言語で型を一生懸命「事前にチェックする」のは良くないという持論を持っている。
その代わり、せっかく備わっている暗黙の型変換を利用して、型を「揃えて」おくのが良いと思う。
例えば自然数入力を期待してpromptを出し続けるのであれば、
do{
n = prompt('自然数') | 0
}while(n <= 0)
で良い事が多いし、良いとするようにする。
この場合入力がキャンセルされた際のnullも、空入力の""も+演算子で0になる。
そういうパターンを活用し、そういうパターンが活用できるようなロジック・仕様を組み立てるのが、
JSをスクリプト言語として上手く活用していく上での１つの答えと思っている。
そういう感じで、nullに関して重要なのは、もっとよく扱えるようにする事かもしれない。
例えば昔から案があって、直近はそろそろ仕様に入りそうなくらい盛り上がってきたこれ
URLﾘﾝｸ(esdiscuss.org)
こういう演算子が入ったりすれば、ますます「事前にチェックする」必要性がなくなる。
159:デフォルトの名無しさん
16/05/15 17:04:24.78 79V1eiQO.net
誤字脱字や凡ミスは良いように解釈してくれ。スマヌ。
160:デフォルトの名無しさん
16/05/15 17:51:57.74 u/cc/woI.net
そういえば 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等の仕事だ。
161:デフォルトの名無しさん
16/05/15 18:16:01.44 gfIC+EQb.net
>>160
アホか。パーサ書いて文脈見ずにreplaceなんかで解決できねえよ。
162:デフォルトの名無しさん
16/05/15 19:03:27.04 u/cc/woI.net
>>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に化けているからこれができない。
163:デフォルトの名無しさん
16/05/15 19:54:18.43 79V1eiQO.net
>>162
URLﾘﾝｸ(httpstat.us)
に対して試してるんだけどそれらの環境で304取得できるよ。
こういうコードで。
xhr = new XMLHttpRequest
xhr.open('get', '304')
xhr.onload = () => console.log('status', xhr.status)
xhr.send()
164:デフォルトの名無しさん
16/05/15 19:55:03.02 79V1eiQO.net
おっと、
xhr.open('GET', 'URLﾘﾝｸ(httpstat.us)')
にしとくか
165:デフォルトの名無しさん
16/05/15 20:00:25.76 u/cc/woI.net
> 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;
と書けるという事だろうけど、こんなところでタイプ量をケチってもしょうがないし、
バグってても見た瞬間修正できるので、正直どうでもいい。
166:デフォルトの名無しさん
16/05/15 20:08:28.09 u/cc/woI.net
>>163-164
サンクス。こちらもそのコードで304を確認した。
ただし俺のスクリプトでは確かに304が200に化けている。
原因究明には少し時間がかかりそうだ。
167:デフォルトの名無しさん
16/05/15 20:45:26.55 u/cc/woI.net
>>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をみすみす捨てているようなものなんだよ。勿体無いだろ？
168:デフォルトの名無しさん
16/05/15 20:52:38.61 u/cc/woI.net
>>158
> 'use strict'強制は、ES2015のclass構文内やモジュール内で達成されている。
確認した。現実的にはこれで問題なさそうだな。
URLﾘﾝｸ(stackoverflow.com)
169:デフォルトの名無しさん
16/05/15 22:01:03.99 u/cc/woI.net
>>163-164
どうやら 強いEtag + nginx + gzip の場合に駄目らしいと分かった。
俺のスクリプトで化けているサイトも該当している。
> URLﾘﾝｸ(github.com)
しかしこれはこちらではどうにもならんな、、、、
とりあえず、XHRの問題ではないことは確かなようだ。
170:デフォルトの名無しさん
16/05/15 22:04:49.13 WWQ4vbR2.net
>>165
優先順位を粗方決めたいだけならServiceWorkerを使えば可能そう。
>>167
つまり何が言いたいかというと、
n = prompt('自然数')
↑
（この型は何だ！？？）
という状態のまま処理を出来る限り進めないということ。
もっと言うと、「n」なのに数値じゃないかもしれない可能性を作らないこと。
このnをあちこちのサブルーチンに配ればあちこちで型に対するチェックや配慮が必要になってしまう。
そうではなく、もうなるべく早く、できればもう変数に最初に入れる前くらいに取りうる値を出来る限り狭めておく。
そうして置けば以降そのnについて心配しなくていいし、そういうのを徹底しとけば
いろんなサブルーチンを書いたり使うときも、引数の扱いで心配することが減る。
JSにおいて型周りで一番多く、かつデバッグが困難なのは、
数値と文字列、そしてそれにパターンマッチが絡んだりする場合だと思ってるので、
特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。
どうでもいいが、変数や引数の型が一定になることはエンジンにとっても優しい。
だがそれで長々とやってたら動的型付け使ってるのが馬鹿みたいなので、
自分は暗黙の型変換（''+、+、|0、のようなもの）を活用する。
まあ「Number(str)」でもいいが、「parseFloat(str)」は嫌いだ。
171:デフォルトの名無しさん
16/05/15 23:44:52.60 9x+kn/QP.net
>>143
こいつダメだ
172:デフォルトの名無しさん
16/05/15 23:55:13.32 u/cc/woI.net
>>170
> ServiceWorker
とりあえずhttps限定の時点で使えない。
気持ちは分かるがそこはユーザに選択させろよなと。
ただchromeが勝手に読みにいく<img>に対して優先かそうでないかを指定できないと意味が無い。
自分が打ち込むXHR内での優先順位ではないんだ。
ただそれ以前に優先順位のつけ方が見当たらないが、どれ？
URLﾘﾝｸ(developer.mozilla.org)
173:デフォルトの名無しさん
16/05/16 00:26:42.96 GmJz87Lv.net
>>170
主張は分かるがそれは完全に「型あり」の考え方だからな。
そうしたいのなら、「型」を導入してキャストするのが一番いい。
つまり、
Int32 n = (Int32) prompt('自然数');
となる。どう見ても Int32 にしかなり得ないと、一目で分かる。
ああ、だからそういった意味で言えば、 asm.js はキャストでもよかったのかも。
彼らは value | 0; で Int32 にキャストしているつもりなのかもしれないが、
それはビット演算を絶対にしない人の感覚であって、
実際にビット演算を使用する人の場合、あの記述だと混ざってしまうのでよろしくないんだよ。
とはいえ、JavaScriptの通常の使い方でビット演算が必要なことはかなり稀なのだけど。
> 特にDOM APIにおいては明示的に数値や文字列にまず揃えることがお作法だと思っている。
いやこの必要なくね？APIは期待した型を返してくるし、そこで引っかかった覚えは無い。
'px'が付いている連中は若干うざいけど、バグったらすぐ分かるし。
ただやっぱ君は「型あり」向きだと思うよ。俺もだが。
var 禁止で全部 Int32, double64, string のどれかに差し替えろといわれても大して不満無いだろ。
174:デフォルトの名無しさん
16/05/16 05:31:59.61 3fs8uQMw.net
>>172
HTTPS必須は、「Let's Encrypt」が一般的に広まって、もっと道入が楽になることに期待する。
SWはXHRに限らず、あらゆる通信をプロキシできる、そしてその種類（image等）が分かるので、
例えばページが開かれてから200msの間全てを保留して、
その間に溜まって、その後も溜まっていくものから優先度の高いと思うのから捌いていけばいい。
ただこれではimg間での優先度が付けられないのでそこは工夫する。
一番簡単なのはhashを使ったりURLに情報を入れる事だろう。（src='～.jpg#high'）
もしくはページ自体の取得もSWを通じて行われるので、もっとアグレッシブにHTMLを解析してリクエストが来る前に読み込んだり、
初回開いたときにリストを作っておいて、次回から利用するとかいろいろ考えられる。
175:デフォルトの名無しさん
16/05/16 08:47:49.06 Pz1/eYkg.net
横から口を出すが
>>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) {}
でも作り上げればいくらでも短くなるだろう(自分で短い仕様を構想すれば良いんだから)
176:175
16/05/16 09:11:44.49 Pz1/eYkg.net
>>154
HTML5でかなりの要素が廃止された
URLﾘﾝｸ(momdo.github.io)
CSS2.1ではかなりの仕様変更がなされた(削除ではないが、変更でも現行CSSには影響力があるものだ)
URLﾘﾝｸ(www.d-toybox.com)
削除ではないが、追加する事で影響を受けたのがtypeof演算子
ES6でSymbol型が増えた事でObject型のチェックが面倒になった
Object (host and does not implement [[Call]])は規定文字列以外の全ての文字列値をとり得るが、"symbol"が追加された事でtypeof arg === "symbol"がObject型ではなく、Symbol型となった
実際、ES6でもType()に相当する機能がないんだよな...
URLﾘﾝｸ(ecma-international.org)
URLﾘﾝｸ(www.ecma-international.org)
177:デフォルトの名無しさん
16/05/16 12:29:46.57 8sje1dNr.net
そういえば、lodashのisObjectは未だに"object", "function"しかチェックしないな
URLﾘﾝｸ(raw.githubusercontent.com)
function isObject(value) {
var type = typeof value;
return !!value && (type == 'object' || type == 'function');
}
178:デフォルトの名無しさん
16/05/16 15:12:30.62 x27HpYqy.net
なんでそういう実装になってるんだろう？
function isObject(value) {
return value === Object(value)
}
の方が素朴で良い実装じゃね？
179:デフォルトの名無しさん
16/05/16 15:16:43.42 x27HpYqy.net
まあはやくReflect.isCallableとか追加されて欲しい、
ダックタイピングぽく、型より機能としてチェックするほうがいいと思う。
180:デフォルトの名無しさん
16/05/16 23:16:06.67 GmJz87Lv.net
>>174
それはやれば出来るかもしれないが、「制御のための制御」になるので駄目だ。
別の言い方だと、それにかかる労力の割りに得られる結果がショボ過ぎて駄目だ。
そこらへんもやはり君はCの感覚なんだよ。「やりきれば出来る」というのがそう。
LL言語だと、「面倒なことは事はやらない」なんだよ。その分動作は遅いけど、手抜きが出来る。
そしてこの手抜きが出来る分、大規模なプログラムを扱うことが出来、
結果的にもっと大掛かりなこともできるという利点につながるんだよ。
分かるか？
勝負するところが違うんだ。
Cのような行単位でチューニング済みの最速コードを目指すのではなくて、
積極的に手を抜いて、結果的に規模の限界を突破することを目指すんだよ。
Cで10k行のコードを扱えるのなら、LL言語では30k行のコードを扱える。
当然やれる範囲が広がるだろ。
JavaScriptは簡単だから馬鹿でも扱えるというのは事実だけど、そこで留まるのではなくて、
それを達人が使ったら何が出来るのか？を目指すんだよ。
普通は「早く仕上げる」ためにLL言語なんだが、それだけではないんだよ。
181:デフォルトの名無しさん
16/05/16 23:32:06.76 GmJz87Lv.net
>>175
> 長すぎる云々
まず文盲で無いことを示してもらおう。これは具体的にどこのことだ？
俺は長さについては問題にしていない。
文盲を相手にしてもどうせ読み間違えまくってくるので議論はどうやっても空回りする。
これはもう既に学んだ。
182:デフォルトの名無しさん
16/05/16 23:37:53.21 oaJCE3x/.net
>>181
>>167の下記だろう
俺のコードは、弾く部分で弾いているだけ。
弾かれる対象を確認するためには、whileの1行を見れば済む。
君のコードは、不正入力は後で弾かれる入力に変換して、結果的に後から弾く構造になっている。
だから弾かれる対象を確認するためには、2行見ないといけない。
記述が分散している分、バグも含みやすい。
183:デフォルトの名無しさん
16/05/17 02:50:45.73 rVqZFYUE.net
> 弾かれる対象を確認するためには、whileの1行を見れば済む。
一行で書けば同じでしょ？
弾かれる対象を確認するためには、どこかの1行を見れば済む。
184:デフォルトの名無しさん
16/05/17 03:25:50.15 rVqZFYUE.net
それに一行に複数の意味を込めたらだめだよｗ
185:デフォルトの名無しさん
16/05/17 09:05:07.26 sIex+koZ.net
>>180
確かに個人的にはそういうコードを毎回書いても楽しいから苦にならないのだが、
何もそうしろと言いたかったわけではなく、一般的に利用するときは
ただそういうフレームワークを読み込んで、各リソースURLに「#priority」を付けるだけ
ってのは十分労力の割に結果がデカイと思うよ。
WebやJSの歴史見ても、「面倒なことは事はやらない」ってより、
「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。
186:デフォルトの名無しさん
16/05/17 13:34:21.32 3yAYzGW4.net
>>167は null, '' しか考慮していない時点でダメ
"123hoge" を撥ねない時点で期待通りに動かない(自然数以外も代入されうる)
187:デフォルトの名無しさん
16/05/17 14:54:21.35 bcEq7422.net
一番ヤバイのはnが文字列であることだろう
後々必ず問題を引き起こす
188:デフォルトの名無しさん
16/05/17 17:31:09.24 ZRrmZHfn.net
>>167は仕様理解者に恨みでもあるのか
「JavaScript知ってる俺カッケー」とか偏見にしても度が過ぎていると思うが
189:デフォルトの名無しさん
16/05/17 19:36:20.35 lpSSxhpK.net
分からんな
演算子による暗黙の型変換を一通り覚えるのは
中級者への登竜門でそれほどハッキーなこととは思えん
Dateのインスタンスだけはプリミティブ化されるとき、
valueOfよりもtoStringの方が先に呼ばれるみたいなことを
前提なコーディングは流石に万人向けではないと思うが
190:デフォルトの名無しさん
16/05/17 22:07:15.55 XBBLWA5H.net
暗黙の型変換は標準メソッドでも行われている事だし、それを覚えずして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('自然数'))) としてもいいが、正直冗長だと思う
191:デフォルトの名無しさん
16/05/17 23:41:38.85 q3gkuA0r.net
>>185
> 「面倒なこと、汚いことは事はライブラリやフレームワークがやる」だった。
正確に言えば、「やるとなると面倒だが、普通はたいていの人が必要とすることは、ライブラリやフレームワークがやる」だ。
これはWebに関わらずプログラミング一般だ。それがライブラリ/フレームワークの存在意義だし。
> 各リソースURLに「#priority」を付けるだけ
になっているライブラリ等が既にあるのかい？それなら確かに導入する意味がある。
それはどれだか教えてくれないか？
（ただ、多分俺の環境では実際に導入することは出来ないが）
いずれにしても、「がんばってまでやりきる」為の言語ではなく、「がんばらずにやれる範囲でサクッとやる」なんだよ。
既にライブラリやフレームワークがあるのなら、「がんばらずにやれる」のでサクッといただきだ。
そういう奴らが多い＋プロプライエタリには極度にしにくいから結果的にいろいろ乱立することになるが、
それはある意味正しい姿といえる。
少し無駄や気に入らない部分があっても、自前で作り直すのではなく、面倒だからそのまま使う、だ。
その1メソッドの中での最適化で勝負するのではなく、
もっと大きい範囲での最適化（サクッと結果が出せるか）で勝負するんだよ。
あと追加。
URLﾘﾝｸ(developer.mozilla.org)
scroll の e に delta がない。
だから糞遅い scrollTop の問い合わせがいちいち必要になる。
.NETだと e.delta でどっち向きにどれだけスクロールしたかが取れる。
同様のことはmousemoveにも言えるのだけど、
あっちは clientX とかがあるから、DOMクエリしなくても追跡できる。
scrollはDOMクエリを強要されるのが辛い。
サンプルも window.scrollYを取っているけど、アレは実は結構重い。
そしてそれがサンプルにあるように、大抵の場合はスクロール位置の確認が必要になる。
192:デフォルトの名無しさん
16/05/17 23:42:45.65 3NFQlF5/.net
Math.floorを使ってもdoubleで扱える範囲でないと仕方ないのは変わりない。
入力が適切に処理できる範囲に収まっているか確認し、大きすぎます等の案内を出す必要がある
193:デフォルトの名無しさん
16/05/18 00:08:03.84 jjsucSg3.net
>>185
あと、ついでならMDNもお願いしていい？
1. URLﾘﾝｸ(developer.mozilla.org)
内のメソッド parse について、
× > JavaScript で日付を表す文字列を解釈して、地方時で 1970 年 1 月 1 日 00:00:00 から経過したミリ秒を表す数値を返します。
○ UTCで
194:デフォルトの名無しさん
16/05/18 00:09:05.81 jjsucSg3.net
>>185
2. URLﾘﾝｸ(developer.mozilla.org)
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の雰囲気とは合わない。
195:デフォルトの名無しさん
16/05/18 00:33:18.17 OcMV4DaZ.net
>>192
そりゃそうだが、随分面倒な処理を要求するんだな
Number 型全体が IEEE 754 の制約を受けるわけだが、制約外の数値を正しく検出するようにしろという事か
対処療法的には入力文字列を正しくパースして数値比較する
根本的には ECMAScript のビルトインオブジェクト全体を書き換える必要があるわけだが、そこまでやる必要あるのかね
196:デフォルトの名無しさん
16/05/18 01:11:57.83 r9bj4L60.net
>>195
君の言う問題点とやらを解消するためにはそこまでやる必要があるというお話さ
そしてそんなに難しく考えなくともdoubleとして受け取るのならNumber.MAX_SAFE_INTEGERを超えてないかどうかチェックすればいいだけ
197:デフォルトの名無しさん
16/05/18 22:06:18.60 Y5c0aQW+.net
>>196
なるほど、理解した
198:デフォルトの名無しさん
16/05/18 22:43:30.32 Y5c0aQW+.net
修正版
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);
199:デフォルトの名無しさん
16/05/18 22:49:59.30 JiGf9hjC.net
誰が完璧な自然数受け付けのロジックを長々と書けといった……
そこまでするなら多長倍数ライブラリ使ったら？
200:デフォルトの名無しさん
16/05/18 23:38:34.48 Y5c0aQW+.net
>>199
初めは while 条件だけで終わらせる予定だったが、
>>192が「大きすぎます等の案内を出す必要がある」と指摘したからエラーメッセージを追加したが、MAX_SAFE_INTEGER だけエラーメッセージを追加するのはおかしいので他のメッセージも追加したら結果的にこうなっただけ
この程度のコードでライブラリを使う必要は感じないが、最近のコーダーはライブラリ使用の見極めが速いんだな
201:デフォルトの名無しさん
16/05/19 03:19:33.36 tfaQOE9Q.net
ってか、キャストしてる時点で型がどうのではなく、型変換してるからな。
普通に、/^[1-9][0-9]*$/するのがいいんじゃねーの？入力は文字列なんだから。
どう考えても、Math.floorに文字列を渡す理由にならん。先頭か末尾に空白あるときはどうなるんだっけ？とか悩むじゃん。
integer.Parse通さないと数字にならないどころか、例外すら発生するのがまともな型のある言語。
202:デフォルトの名無しさん
16/05/19 04:45:29.52 3i7lekC+.net
>>201
JavaScriptは型違いをTypeErrorとせず、暗黙の型変換をする言語なんだから型変換で正しいんだよ
203:デフォルトの名無しさん
16/05/19 05:59:57.75 tfaQOE9Q.net
>>202
知ってるよ…だから、型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。
204:デフォルトの名無しさん
16/05/19 07:31:01.14 l0qmM6vP.net
>>203
> 型のアノテーションがどうだとか、型を定義すべきだって話が眉唾と言うか、良い所全部殺すなって思うんよね。
文脈を読めてないんじゃない？
型付き言語にこだわっていた人と>>198は別人
205:デフォルトの名無しさん
16/05/19 08:30:40.64 F9dbx1t6.net
JavaScriptは型付き言語でないわけで、そこに型付きな考え方を付加させても、各々のポリシーでいかようにでもスタイルが変化するって事をわかってない感じ
また、型付き言語であっても変数に代入されるまでは型が確定されないわけで経過処理で型変換を挟んではいけないわけではない
206:デフォルトの名無しさん
16/05/19 13:24:53.83 qyR8CUMd.net
入力は限られてるし、取り扱いを間違っても原則ブラウザがクラッシュしたりすることはない。
それどころか不意に関数エラーが出ても、こういったイベントドリブンな場合は、何も問題なく復帰できることも多い。
最悪詰まっても、文章は読める。そこが所謂低レベル言語との違い。
207:デフォルトの名無しさん
16/05/19 13:36:54.99 Gndv5tvj.net
LLマンセー
208:デフォルトの名無しさん
16/05/19 14:55:40.45 XceO64sZ.net
何も自慢できない男の人って可哀想(;;)
209:デフォルトの名無しさん
16/06/09 09:39:33.79 FTTkP1ld.net
arrow function の引数の丸括弧を省略する記法嫌いな人って多くないのかな
const fn = arg => { console.log(arg); };
const fn = (arg)=>{ console.log(arg); };
210:デフォルトの名無しさん
16/06/09 13:20:53.39 bsniAtVU.net
時と場合によるだろう。
この場合は、あった方が良い
211:デフォルトの名無しさん
16/06/09 13:43:16.42 QTm6YzLa.net
>>209
省略記法全般が嫌い
{} の省略の方が嫌だな
しかし、このアンケートに意味があるとは思えんのだけど、ただ雑談したかっただけ
多いか少ないかなんてどうでもいいと思うが
212:デフォルトの名無しさん
16/06/09 13:43:46.11 QTm6YzLa.net
ただ雑談したかっただけ？
213:デフォルトの名無しさん
16/06/09 14:51:10.11 eWu1TzV4.net
>>209
省略できるものは原則省略したほうがいい。セミコロンも含む。
短く書けるとき、あえてそうしないというのは、
何らかの特別な意味を表す必要がなければしない方がいい。
214:デフォルトの名無しさん
16/06/09 16:09:58.83 bsniAtVU.net
>>213
そういうのは、ミニファイツールでOKでしょう。
コーディング中は、原則省略すべきじゃない。
GitHubで公開するソースも省略するべきじゃない。
可読性を下げてはいけない。
省略した方が読み易いとか云う奴は、独りよがりの変態なだけ
215:デフォルトの名無しさん
16/06/09 20:35:01.66 ziShIi0x.net
>>213
釣りはウザイから止めろ。
ガチで勘違いしているのなら google のコーディングルール読め。駄目な例まで挙げてある。
URLﾘﾝｸ(cou929.nu)
>>209
一般にどうなのかは分からんな。
しかし所詮は慣れだろうし、世間がそう書くなら慣れるしかないのでは。
なおそのケースなら俺は function と書くが。
sortの引数のような最初から function であることが確定している部分はいいけど、
それ以外の所（何が書かれるか分からないところ）には function と書いた方が見やすいと思うから。
216:デフォルトの名無しさん
16/06/11 16:34:28.13 tWgkOxEq.net
>>214
いいや、無駄なものが付いてるほうが可読性が落ちる。
特にGitHubではセミコロン省略が推奨されてるでしょ。
URLﾘﾝｸ(github.com)
それなのに付けろというのはそれこそ独りよがりだよ。
でも君が独りよがりだから悪いとは言わないよ。
JSは独りよがりで自由であるべきだからね。
217:デフォルトの名無しさん
16/06/11 16:40:46.73 tWgkOxEq.net
>>215
釣りではない。
GitHubやnpmなど、セミコロンフリーのスタイルは確立されている。
自分も様々なスタイルを試した結果、今はこれに賛同しているだけ。
ただし、この２つは同じく原則省略でも細部の取り回しが異なる上、自分もそれらとは微妙に異なる。
ルールセットの他の部分は当然違う。結構細かくいろんなスタイルが存在する。
そのどれもが考えられてるのだから悪いとかフザケてるとか思うようなことでないと思う。
それなのに人の信念というか、正義を釣り呼ばわりするのはかなり独りよがりだと思う。
でも落ち込まないで、そんな君も好きだよ。
218:デフォルトの名無しさん
16/06/11 17:39:28.29 ZhHlBSFM.net
>>217
キモいわ。
個人が作った勝手ルールだろ。それに従いたければ勝手にしろよ。
googleの方は「こういう問題があるから、こういうルールにしました」という、極めて実用的なものだ。
俺がgoogle側のルールを妥当とするのはこの点からだ。
コーディングルールは、見やすさではなく、バグを含まないためにある。
セミコロン程度の見やすさなんて、所詮慣れでしかない。
付いている方が無駄バグが発生しにくいのなら、当然それがルールで、見にくいのなら慣れろ、という立場だ。
お前はこのスレに来るべきではない。テンプレ読めよ。
お前は3,000行のコード、書けないだろ。
219:デフォルトの名無しさん
16/06/11 19:12:42.34 ZhHlBSFM.net
>>217
つうかおめー、マジで頭おかしいぞ。
有名どころは全部「セミコロン付けろ」だぞ。
個人レベルでの勝手ルール持ち出すとか、キチガイだと分からないか？
それともGitHubを勘違いしているか？あれは誰でもアカウントを作れる。もちろん君でも。
> JavaScriptのスタイルガイドまとめ(おすすめ4選)
> jQuery JavaScript Style Guide
> Airbnb JavaScript Style Guide
> > URLﾘﾝｸ(github.com) (star 36,207、対して feross は 5,886)
> Node
> URLﾘﾝｸ(qiita.com)
220:デフォルトの名無しさん
16/06/11 19:13:01.99 ZhHlBSFM.net
> npm
> URLﾘﾝｸ(www.npmjs.com)
npmだけは確かに「省けるセミコロンは省け」と言っている。
ざっくり見た感じは、「JavaScriptについてよく知れば、それが出来る」ということらしい。
つまり、どういうケースでAutomaticSemicolonInsertionが動くか理解して、
常にそれを考えながらコーディングしろ、ということなのだが、
そんなことやってるからJavaScriptの連中は上達してないんだと思うけどね。
本来のプログラミングの「技能」は、言語をまたいで汎用的なものだ。
その言語でしか使えない知識は、「文法」でしかない。
俺たちはJavaScriptのおかしな文法を極めたいわけでもない。JavaScriptを使いたいだけだ。
君の論理なら、使いたいだけのために勉強を強いるのもまた「独りよがり」でしかないだろ。
不思議なのは、JavaScriptの連中にはこの主張をする輩が多い事だ。
npmが震源だったということなのか？
C++で「テンプレートを極めてから来い」
C#やJavaで「クラスライブラリを極めてから来い」
なんていう奴はいない。それはどだい無理だからだ。
だから知っている範囲でコーディングを開始していく。そして「そんな機能あったのか！」ってのも割とよくある。
JavaScriptはギリギリ極められるくらいの軽量言語ではある。
しかしだからといって、それを極めたところで益はない。せいぜいセミコロンが省けるだけだ。
そんなことに時間をかける価値なんてないだろ？
全部セミコロン付けてリントで落とし、さっさと本題に行こうというのが普通だ。
221:デフォルトの名無しさん
16/06/12 00:32:26.03 npk74fIw.net
詳細確認したが、
> セミコロンフリー (>>217)
ではないぞ。
> // ok
> ;(function () {
> window.alert('ok')
> }())
>
> // avoid
> (function () {
> window.alert('ok')
> }())
> URLﾘﾝｸ(github.com)
必要な時には行頭に付けろという、一周回った発想だ。
222:デフォルトの名無しさん
16/06/12 00:33:54.14 npk74fIw.net
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.
> URLﾘﾝｸ(blog.izs.me)
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.
> URLﾘﾝｸ(inimino.org)
3つ目は「関数には要らなくて関数式には付けろとか『初心者には』分かりにくい」ということだった。
> URLﾘﾝｸ(www.youtube.com)
よく見るとなるほどこのnpmのコーディングルールの作者がferossか。
ならばそれは「GitHubで確立されている」とは言わない。それは君がGitHubを勘違いしているだけだ。
GitHubはただの置き場であって、誰でも何でも置けるんだよ。プログラムである必要すらない。
とはいえnpmではある程度の評価を得ていることは事実だな。ただ明らかに主流ではないが。
セミコロン無しの有名言語はRubyとPythonだと思うが、そっち出身でなければ大人しく付けておいて、それに慣れた方がいい。
Ruby/Pythonとの相互運用なら可能性はありだが、
俺はRubyもPythonも知らないのでどちらがマシかの判断は付かない。
223:デフォルトの名無しさん
16/06/12 05:22:59.97 Q2nOr0zy.net
>>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のデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
でも分かった。そういうのを他人に求めるのはエゴなんだと。
すまなかった。。。。。。。
224:デフォルトの名無しさん
16/06/12 05:36:18.79 Q2nOr0zy.net
>>220
極める必要なんてない。
例えば暗黙の型変換周りと比べると非常に明快。
ただ、「括弧で始まる前に付ける」。
これさえ守ればいい。
細かいこと言えば『接続させたくない』接続可能な他の演算子の前にも付ける必要などあるが、
まずそうであることはありえない。
そして「括弧で始まる」ようなものを書くようになるのは入門終了後だから、
その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。
225:デフォルトの名無しさん
16/06/12 05:49:08.10 GMtpRE4O.net
>他人に求めるのはエゴ
はいこれで決着ね
226:デフォルトの名無しさん
16/06/12 11:40:13.85 npk74fIw.net
>>223
いや悪いが「キモイ」ってのは君の投稿内容のことであって、JavaScriptの記法の事ではなかった。
ここは馴れ合う場所ではない。
ただやはりそれは努力の方向を間違っていると思うよ。
先に書いたように、「文法」を覚える努力をいくらやったところでプログラミングの「技能」は上達しない。
勉強する前に鉛筆の削り方に異常にこだわるようなものだ。さっさと勉強を始めた方がいい。
> class構文やプロトタイプ的継承術に慣れた後では
> JSのデフォの継承システムが一番「存在的にキモい」ことに気づくのと同じ。
釣りか？JSのデフォの継承システム＝プロトタイプ的継承だが。
> その程度の「決め事」と一緒にそれらの書き方を学ぶのが特に負荷になるとは思わない。
「とりあえず全部セミコロンつけとけ」の方が楽だ。何も学ぶ必要はない。(JSなら余分も問題にならない)
なお、JSの場合はセミコロンは「必要な場所に無ければ挿入される」であって、「不必要」ではない。
そして return の場合は改行でいきなり終端されるとか、動作に一貫性がない点もある。
たぶんRubyやPythonは最初から「不必要」で設計されている。この点が違う。
227:デフォルトの名無しさん
16/06/12 11:40:36.40 npk74fIw.net
インターネット上で自分と同じ意見を探すのは、使い方を間違っている。
最近「ブサヨ」「パヨク」とか言われているだろ。あそこまで見事に「裸の王様」になるのかとも呆れるが、
君は彼等と同じインターネットの使い方をしている。
どんなマイナーな意見でも、世界中を探せば同意見の奴は大概見つかる。自分が世界一マイナーな確率なんてほぼゼロだから。
だから、検索でヒットしても安心したら駄目だ。それはどれくらい支持された意見なのか確認する必要がある。
大勢が採用した物には、それなりの理由がある。マイナーならばそれにも理由がある。
君にはJavaScriptの技術力もないし、
マイナーな意見をGitHubの大勢だと勘違いしてしまう程、インターネットのリテラシーもない。
もちろん何故大勢が「セミコロン付けろ」なのかも分からないだろ。
余分な苦労をせずに上達したいのなら、「普通に」色々やった方がいい。もちろんそれも含めて君の自由だが。
そしてやはり君はここに来るべきではない。邪魔でしかない。
この手の「議論以前の常識」についてグダグダ言いたくないから別スレを作ったんだ。
君は「質問スレ」でいいはずだ。彼等はこの題目なら嬉々としてレスしてくるだろうし。
228:デフォルトの名無しさん
16/06/12 11:50:23.91 k/2WgB7H.net
ここまで静観して見てたけどその例えはどうなのよ
Web板での政治社会的なレッテル貼りや質問スレの～行以下のコード云々の煽りはともかく
このスレでだけはまともに議論や情報交換をするものだと思っていたのに心底残念だよ
229:デフォルトの名無しさん
16/06/12 12:18:41.79 bynAnAmH.net
セミコロンは付けるか付けないかではない。付けさせるか付けさせないかだ。
そう考えれば付けさせるしかないだろ。
230:デフォルトの名無しさん
16/06/12 12:24:25.95 npk74fIw.net
>>228
では出ていくなり、他スレを立てるなり、好きにすればいい。それも自由だ。
ここは言いたいことを言い合う場所であって、言って欲しいことを言ってもらえる場所ではない。
どこについて怒っているのか若干謎だが、
「ブサヨ」「パヨク」については適切な例えだと思うぞ。実際そうだし。
ただ彼等について嘲笑するだけなのは、それもまた駄目なんだよ。
自分もそこに陥ってしまう危険性に気づき、他山の石としなければならない。
実際、彼もその罠に嵌っているわけだし。
マイナーな状態で旗印があれば信者はそこに飛びつく。
そして周りが自分と同じ意見であることに安心してしまうのだが、それでは駄目なんだ。
セミコロン無し派がnpmに集結しているのは正直驚きだった。だから詳細を確認した。
結果、「宗教」だった。対してgoogle/jQuery/Node/Airbnbは「実利」だ。俺はノータイムで「実利」を取る。
とはいえ、いずれにしても「宗教」の時点で議論する意味はない。
どうあがいても平行線だからね。
だから結局好きにするしかないのだが、セミコロン付ける派にも「宗教」の奴はいるはずで、
人口が C/C++/Java >> Ruby/Python な以上、「宗教」としてもひっくり返らない。
だから変にこだわるのではなく、「セミコロンあり」に慣れるしかないだろ、というのが至極妥当な見解だと思うが。
231:デフォルトの名無しさん
16/06/12 12:26:16.47 3NjnbAB7.net
>>228
ここで議論したことあるけど、高確率で煽る方向に絡まれるから有意義な議論は期待できないと思うよ
議論中に軌道修正しようとしたけど、ほとんどが無駄だった
232:デフォルトの名無しさん
16/06/12 12:33:31.15 npk74fIw.net
>>229
そうなんだけど、セミコロン無し派も結構ガチなんだよ。
リンターも整形ツールも既に提供している。
あのferossって奴もGitHubの垢見る限りそこそこ大物だ。
ただ正直、そこまでこだわる理由もよくわからんのだが、、、
233:224
16/06/12 16:06:44.39 gONGsgja.net
>>227
俺はここはJSを愛する者達のスレ、と認識していた。
今は亡きECMAスレの面影を重ねているのかもしれない。
要するに、より良いJSを目指す者質の意見だ。
ただの常識とやらにそった意見の飛ばし合いならばそれこそそこらの質問スレですればいい。
こういう議論をするためこそにこのスレが有るのだし、
現にこういう議論が出て初めてスレが伸びたんだからそういうことに違いないだろう。
ともかく、こういう議論をすること自体は良い。としてもらいたい。
>>229
彼に少しでも良いJSを目指したいという精神が感じられなければ、またこういうスレでなければ俺も「あえて」付けるなとは言わない。
この場所、このタイミングで質問した彼には真実に繋がるヒントを伝え、そこへ目指して欲しかった。
>>230
>>「慣れるしかない」
どうして？いや、仮に「セミコロンを原則付けること」に慣れる必要があるとしても、
「セミコロンを原則付けないこと」にも慣れてはいけない理由なんてないし、
そっちを普段自分の中でメインで使って良くない理由なんてないよな。
>>232
俺がこだわっているのは、「セミコロンを付けないほうがいい」ということよりもむしろ、
そういうことを教えたり教わったり考えたり、もっと自由な研究をしようよということだな。
た だ し、『プログラマー』『スクリプター』『JSer』になりたいのならね。
そうでないのならどうでもいいが、俺はそうなってほしい、JSを愛して欲しいと考えるからこうした立場をとっている。
JSを教えるとき、JSって、スクリプト言語って、プログラミングって楽しいんだよ、深いんだよ、広いんだよ
ということを感じてほしくはないかい？俺は欲しい。
一緒にJSを味わい尽くし、発展に協力してもらい、共に夢を見る関係になりたい。
そう思うことはそんなに変かな。
このスレでは許されると思ったんだけどね。寂しい。。
234:224
16/06/12 19:04:38.68 gONGsgja.net
あー、それとここまでの流れをちゃんと見てみたら混乱を招いてるようなので
一つ断っておきたいんだが、俺はバランスタイプなんだ。
俺が「セミコロンを付けないほうがいい」などと言ってるのは、
あくまで彼に対するレスが偏り過ぎないよう、不足分を埋める立場になっただけで、
その瞬間ではあくまで彼のためだけの、彼の方向に向いたレスでしかない。
他のレスとは補完関係であって、互いに影響を及ぼしたり対立したりするつもりはない。
もし他の人が「セミコロンを付けないほうがいい」といったならば、
俺は逆の立場から言っていた。
あくまで俺の目的は、広く深い心と知見と情熱を持った『JSer』育成にあるからだ。
何か１つのそれっぽい答えを貰うだけで満足してほしくはない。
いろんな案を受け入れ、自ら試行錯誤してより良いJSを追求していって欲しい。
235:デフォルトの名無しさん
16/06/12 23:59:15.39 NYt/6ntu.net
自転車置き場の議論てやつだな
あほだな
236:デフォルトの名無しさん
16/06/13 00:25:03.07 AxmCg6hy.net
>>235
ほう、名詞があるんだね。
色々考えたんだけど、JavaScriptの連中が上達してない原因は多分そこだと思うんだよ。
C初心者「for文、while文、if文…」
JavaScript初心者「for文、while文、if文…」
C初心者「ポインタ…」
JavaScript初心者「セミコロンはどこに打つべきか議論しよう(ｷﾘｯ」
C初心者「ポインタ…ポインタ…構造体…」
JavaScript初心者「暗黙変換の活用について(ｷﾘｯ」
多分、本質的でないところにトラップされてるんだ。
Cはこの点、寄り道無しで初ボスかつラスボスのポインタがいきなり出てきて勇者は死ぬ。
そして何度も復活の呪文を唱えつつ、そこを抜ければいきなり中級者になってる。
JavaScriptの連中は完全にここで空回りしてしまってる。
セミコロンを打つ場所なんてマジでどうでもいいのに、さも重要なことのように言うのは詐欺だよな。
237:デフォルトの名無しさん
16/06/13 06:36:45.25 o3uO7eJP.net
>>236
実際には、セミコロンを打つ位置ではなくて、なぜセミコロンが省略でき、その場所では省略してはいけないのかが問題なんだけど、題目的にしか議論してないからな。
ポインタだって、参照と実体とかにフォーカスした方がいいんだろうけど、その辺スルーだし。
238:デフォルトの名無しさん
16/06/14 10:56:42.92 ScASA3Ww.net
>>236
一番重要で本質的なことは、
長く複雑なコードをいかにスマートに書けるか、
いかに問題を短く簡潔なコードで早く書けるか、
ってことだと思うよ。
各機能がどうのこうのは、それこそどうでも良いというか、
基礎という意味では重大だけれど、レベルが低いことだと思う。
セミコロンを打つ場所なんてマジでどうでもいいというのは、
それは初心者にとってそれよりも先にやるべきことがあるからその通り。
しかし中級者以降生産性やコードの質を上げていこうと思えば
この手の物事の重要性は増していき、最後には信念やら宗教やらと言われる問題に行き着くと思うよ。
ここは既習者スレなんだから、そういうことこそを話し合うべきだと思うけどな。
そして空回りしているというのは、ある見方ではそうだと思う。
JSは仕様の内も外も具体的な実装について殆ど意識されていないからね。
でもそれは逆に、具体的な実装に囚われず概念を学べると言えると思う。
その概念を習得すれば、例えば他言語に移ったとしても柔軟に対応できる。
他にもJSはマルチパラダイムと強く意識されて作られたわけではないが、その真似事ができる。
むしろJSこそ最も様々なプログラミングにおける本質的な物事を学べる言語だと思う。
239:デフォルトの名無しさん
16/06/14 18:26:48.94 TG3hSyiU.net
検索用にセミコロンを 2 個3 個続けるのもありかな
240:デフォルトの名無しさん
16/06/15 01:26:31.98 Iz/1ukPU.net
検索用にセミコロンを 2 個3 個続けるのもあり
と君が判断したのなら君の中ではありなんだろう
241:デフォルトの名無しさん
16/06/15 20:32:12.77 AdfPujMx.net
マンセーが異様に多いのもJavaScripterのおかしな所だよな
242:デフォルトの名無しさん
16/06/16 07:55:44.05 oMjTOMdB.net
そうか？
むしろスクリプト言語の中じゃ代表コミュニティもないし、そういうのは少ないほうだと思うが。
243:デフォルトの名無しさん
16/06/16 08:00:04.44 88N1/vwg.net
利用人口ぱねえからな。変なの目にする機会も多かろう。
244:デフォルトの名無しさん
16/06/16 15:16:35.80 oMjTOMdB.net
他人を理解できないってのは悲しいね
245:デフォルトの名無しさん
16/06/18 01:00:30.57 HfDVf1Az.net
>>243
人数自体はそんなに大したことはない。
おかしな奴の割合が異常に高いんだよ。
Webがホームということもあり、未熟な奴が平気で情報発信()している感もあるが。
URLﾘﾝｸ(www.tiobe.com)
URLﾘﾝｸ(spectrum.ieee.org)
URLﾘﾝｸ(pypl.github.io)
246:デフォルトの名無しさん
16/06/18 05:23:04.56 bYpIs91z.net
マンセーしたら未熟者扱い？
エキスパートな俺様は苦しんでるのに許せない間違っているってことだろうか
それとも辛い経験豊富で批判的な俺様カッケーって勘違いアピール？
傍から見るとひねくれ者の妬みにしか見えないが……
247:デフォルトの名無しさん
16/06/18 14:06:50.57 P96CWXJR.net
観測範囲の問題
JavaScriptに限らず、おかしな人はどこにでもいる
このスレの>>1は相当な変わり者だったようだが
248:デフォルトの名無しさん
16/06/19 04:58:43.41 pwKRdbbJ.net
おかしくない人って何よ
249:デフォルトの名無しさん
16/06/19 10:12:00.06 0NV3J/pF.net
>>245
Google で検索されたキーワード辺りで指標作った方が良さげな気がする。
250:デフォルトの名無しさん
16/06/19 12:28:35.73 XPavHURr.net
ここは>>1を含めて俺様主義の人が常駐してるのでまともな意見交換は出来んよ
始めは冷静でも、少し意見の食い違う人が現れただけでただの「主張の押しつけ合い」に発展する
意見交換するなら「そんな考え方もあるのか」ぐらいに自分の立場を引いて見つめる客観性が必要だが、彼は否定にかかるだけで相手をやりこめないと満足しないからな
251:デフォルトの名無しさん
16/06/19 15:16:34.64 pwKRdbbJ.net
俺もお前も仙人や神様じゃなく凡人なのだから、性質に割り振れる度合いは限られてる。
結局思考停止の傲慢くんも、視野無限の優柔不断くんも、同じくらい悪い議論しかできない。
その中間であっても、両者の悪いところを半々持つので、同じくらい悪い議論しかできない。
つまり無理難題夢物語ということ。「こんな議論もあるのか」ぐらい許容的になってもよかでは？
252:デフォルトの名無しさん
16/06/19 17:29:39.15 +1vne4gn.net
そうやって他人の人格否定する辺りがまともな議論が成立しない理由なんだよな
URLﾘﾝｸ(d.hatena.ne.jp)
253:デフォルトの名無しさん
16/06/19 19:27:30.52 fmRoj+h3.net
そこで言う「まともな議論」とやらをここでする必要が有るのかい？
仕事でもあるまいし、自己主張のたまり場でもええんやないの？
254:デフォルトの名無しさん
16/06/19 19:36:59.62 J/2rkjpj.net
ここは電波を黙らせる方法がないのだから基本は自己主張のたまり場にしかならんよ
その状態で有益な議論に出来るかは当事者次第でしかない
255:デフォルトの名無しさん
16/06/19 20:13:29.92 fmRoj+h3.net
まあぶっちゃけ単純に「聞き手」不足なだけなんだけどね
256:デフォルトの名無しさん
16/06/19 20:36:57.86 J/2rkjpj.net
そうか？なら語って、どうぞ。
なおセミコロンについて語られても困りますので悪しからず。
257:デフォルトの名無しさん
16/06/19 22:34:40.11 YTnkZ+TT.net
自己主張の溜まり場なら「情報交換所」なんてタイトルを付けなければいいのにな
次スレは「JavaScript自己主張の溜まり場」に改名すればいい
258:デフォルトの名無しさん
16/06/19 22:50:20.08 J/2rkjpj.net
単発にはキチガイしかいないことの再証明乙
259:デフォルトの名無しさん
16/06/19 22:55:12.64 YTnkZ+TT.net
ID:J/2rkjpj
自己主張の溜まり場で有益な議論が出来る訳なかろう
キチガイといっている時点でおまえにはその気が全くないのだろうが
260:デフォルトの名無しさん
16/06/19 23:05:07.79 YTnkZ+TT.net
>>251のよつな相手の非を盾に自分の非を正当化する行為も議論には邪魔だな
自己勝手の押しつけが横行するようなら「JavaScript自己主張の溜まり場」がこのスレに相応しい名前だと思うぞ
261:デフォルトの名無しさん
16/06/19 23:09:03.89 J/2rkjpj.net
やりたきゃ自分から始めればいいし、それに誰も食いつかなければその程度だったってだけだろ。
誰も池沼を相手にしたくないし、する義務もないんだよ。
何かあるのならさっさと始めろよ。
262:デフォルトの名無しさん
16/06/20 12:16:18.08 GHIZIB85.net
スレタイ詐欺だな
263:デフォルトの名無しさん
16/06/20 23:23:32.99 ismdVjCJ.net
基本的にこのスレは>>1しかいないからこうなるわな
賛同者がいないことを盾に本題への言及を避けてるだけ
264:デフォルトの名無しさん
16/06/20 23:45:23.34 hAl2oYmp.net
「本題」って何？
265:デフォルトの名無しさん
16/06/21 11:22:12.62 papOtBqK.net
>>257
266:デフォルトの名無しさん
16/06/21 13:37:07.53 NcocGzZA.net
つまりかつてのECMAスレみたいに、いろんな新情報を挙げていけばいいんでしょ？
でもそれから派生した議論は別問題だよ。
匿名掲示板なんだから、自己主張の溜まり場になって当然。
逆にそうでなくすことなんて無理無理。道理に反してる。
俺は質問スレ10くらいの時から100スレ間に渡っていろんな案を出して直そうとしてきたが、
まあ様々なところで一定の収穫はあったが、議論が暴走することだけはどうしようもならなかった。
なら逆に受け取る方が考え方・気持ちを切り替えていくしかないんだよ。
267:デフォルトの名無しさん
16/06/21 16:31:29.25 wNHblGP/.net
新情報っていってもねぇw
268:デフォルトの名無しさん
16/06/27 00:33:14.94 n3Kagte5.net
TypedArrayとasm.jsの状況について詳しい人居る？
現在アプリにもっさり感がある。それであちこち修正したのだが、
ChromeDevTools/Profiles/CPU PROFILESで(program)が70-90%なのでJS側での速度改善はほぼ頭打ちだ。
そこで無理やり使用メモリを減らして速度向上させようとしている。
なお、評価はchromeで行っている。
JSのArrayは例えば [0,0,0] なら 16(header)+8*4(contents) = 48 Bytes になるようだ。
一つ中身が多いのは多分length分だろう。
元々オブジェクトだった物(26+88=116Byte)を強引にArrayに変えてこれを実現した。（項目も減らした）
ただ実際は struct { Int32, Int32, Int64 } なので本当は 16 + 4+4+8 = 32 になって欲しい。
そこで質問なのだが、
・asm.js 的記述（代入時に全部 |0 )したらメモリ確保も32bitになるかどうか
・TypedArrayの状況
を知りたい。
通常asm.jsは速度面ばかり話に出ていて、メモリ面の話が無い。
とはいえJITだと普通は無理だと思ので、
他の含めて何らかの方法でメモリ確保量を減らす方法を知っていればよろしく。
以下を見る限り、そういう用途向けではなさそうだが。
URLﾘﾝｸ(www.h2.dion.ne.jp)
TypedArrayは使用メモリ自体は確実に減らせるはずだが、速度が異常に遅いのが気になっている。
以下で俺の環境だとざっくり7/7/100+/300+(以降全部)とかだ。
URLﾘﾝｸ(jsdo.it)
余計もっさりするようでは意味無い。試したことがある人は居るかい？
ググッたが、TypedArrayについては軒並み記事が古く、しかもやはり「遅い」という物が多い。
269:デフォルトの名無しさん
16/06/27 00:37:31.51 rG4NGWrk.net
生成が重いだけだろ
使い方を間違えてる
270:デフォルトの名無しさん
16/06/27 01:40:09.28 n3Kagte5.net
一応全体的に遅いということなのでそうだと勝手に思っていた。古いが以下。
URLﾘﾝｸ(blog.livedoor.jp)
とりあえず確かめてみた結果、読み書きは1.5倍程度遅い。
許容範囲かといわれれば微妙だな、、、、
なおデータがなかなか安定しなかったので、若干怪しい。
サイズは俺が使う予定の1000にした。
このサイズなら確保との差が見えないが、オリジナルのサイズ(1.6M)だと見えていた。
function testArray(data, n, iter, start) {
var time_enter = Date.now();
for(var j=0;j<iter;j++)
for(var i = 0; i < n; i++) data[i] = i & 0xFFFFFFFF;
var now = Date.now();
return [now-time_enter, now-start];
}
function check(iter){
var start = Date.now()
console.log('array: '+testArray(new Array(count), count, iter, start));
start = Date.now();
console.log('Int32Array: '+testArray(new Int32Array(count), count, iter, start));
}
var count = 1000;
for (var i=100;i<100000000;i*=10) check(i);
271:デフォルトの名無しさん
16/06/27 01:40:47.25 n3Kagte5.net
array: 1,2
Int32Array: 2,2
array: 2,2
Int32Array: 4,4
array: 22,22
Int32Array: 35,35
array: 235,235
Int32Array: 369,369
array: 2544,2544
Int32Array: 3665,3665
array: 24831,24831
Int32Array: 36757,36757
272:デフォルトの名無しさん
16/06/27 02:01:59.30 n3Kagte5.net
しかしどうやっても Int64 を生成できないのが問題だ。
実装としてはInt64を使わずにdouble64なのかな？
だったら変換が毎回発生せずに済むからいいけど。
273:デフォルトの名無しさん
16/06/27 02:43:48.33 Krh8v6Tl.net
> しかしどうやっても Int64 を生成できないのが問題だ。
はぁ？
274:デフォルトの名無しさん
16/06/27 02:59:51.93 rG4NGWrk.net
Chromeで試したけどInt32Arrayが全て上回った
275:デフォルトの名無しさん
16/06/27 03:37:44.60 1KZKLXAx.net
>>268
> 他の含めて何らかの方法でメモリ確保量を減らす方法を知っていればよろしく。
オブジェクトプール使え
276:デフォルトの名無しさん
16/06/27 04:57:14.28 Hl6kI6LE.net
>>270
古いが、じゃない。あまりにもあまりにも古すぎる。
例えばV8は1年前はasm.js用の特別な最適化はしないと言っていたのが、
今では実装がほぼ完了している。
時代の流れというのはとてつもなく早いのだよ。
半年以内の記事でないと評価に値しない。
>>268
通常配列の最適化はエンジンによりまちまちだが、共通して言える分としては
全要素がSMI（≒Int32）かDouble時の最適化のみ。
SMIの要素にDoubleが交じるとそれはDouble配列として最適化される。
そして確かにasm.jsベースで書けば理論的には最大パフォーマンスに近いものが作れるだろう。
でもそれは例えば変数は同時にレジストリに乗る程度の数個に厳選して、
他は全て型付配列のアクセスに置き換えるテクから始まり、
メモリ上のデータの配置にまで気を使って初めて実現できること。
勿論大本のアルゴリズムは言うまでもなく最適でないといけない。
それが昨日今日asm.js始めたばかりの人間にできるかといえば否。
昔アセンブリで最適化してた経験でもないと人力では限界がある。
>>272
もし本当にInt64を効率よく扱いたいのなら時代が追いついていない。
丁度今議論中。３年後にどうぞ。
277:デフォルトの名無しさん
16/06/27 17:22:50.14 PSQIpa+S.net
Int64はなんでないのかねえ
278:デフォルトの名無しさん
16/06/27 18:12:51.74 8aVYS4Ar.net
逆に考えればすぐ答えは出るよ
何故Float64Arrayはあるんだろうと
279:デフォルトの名無しさん
16/06/27 23:12:26.18 n3Kagte5.net
>>275
今回は保存用（内部保持データ）なのでそれは使えない。
>>276
> 半年以内の記事でないと評価に値しない。
それはそうだが実際に遅い。
FF(47.0)でも試したが、上記ほどの差はなく、ほぼ1倍だった。
絶対値としては両方ともchrome(50.0.2630.1 canary SyzyASan)のInt32Arrayとほぼ同じで、
chromeのarrayが速いだけのようだ。
なお古いchrome(49.0.2623.112 beta-m)でも試したが傾向は同じ。(ただし全体的になぜか5倍ほど遅い)
とりあえず環境によるのかもしれないので、>>270の結果(>>271)を環境とともに貼ってくれれば助かる。
コピペすればそのまま実行できる。当たり前だが数字が大きい方が遅い。
なお>>271はchrome(50.0.2630.1 canary SyzyASan) + Vista だ。
> そして確かにasm.jsベースで書けば理論的には最大パフォーマンスに近いものが作れるだろう
いや、だからそれは「局所的」速度の話だろ。
俺は「全体的」速度を上げようとしている。
不要なオブジェクト生成はしていないので、メモリ攪拌はない。
ただし、どうしてもキャッシュミスは多いはずなので、これを改善しようとしている。
アクセスは150個単位で行われるため、TypedArrayにまとめてしまえばキャッシュヒットするようになる。（はず）
URLﾘﾝｸ(sites.google.com)
ただ、今はそれ以前の段階で、全体的なメモリ使用量を削減しようとしている。
280:デフォルトの名無しさん
16/06/28 15:51:09.22 +n63MTqJ.net
あのねぇ、銀の弾なんてないのよ。
JIT用最適化ってのはね、理論が正しくても１つ書き間違えただけで台無しになったりするし、
小さなベンチの結果では大きなコードの結果が予測できないこともある。
それこそ最も確実なのはAOTで予測しやすいasm.jsに出来るだけ落としこむことなのよ。
JITの範囲で君の書いたどんな代物か分からないコードが、
どうすれば良くなるかなんて最早一般的な話ではできないのよ。
もうどんな見るに耐えなくなっても良いのでとにかく速さだけを追求したいということなら、
それはもう人が書くようなJSでなくなることは確か。
そこまで行かずとも、今よりいくらか無難に改善したいということなら、
それこそそのコードに依存するとても細かな話で難しい。
というか君もそういう密接な協力をして欲しそうな態度を取ってないし、
結局はただ自分がやってることの進歩を見て欲しいとか、
寂しくないよう日記のつもりでここに書きたいだけでしょ？
そういうのが悪いとは思わないけど、ただ返信してくれた相手を否定する病を発症しちゃあオシマイよ。
そこは君の弱さだよ。
281:デフォルトの名無しさん
16/06/28 20:52:20.95 A7Bg25Ta.net
そう思いたければそれでいい。
ただ、その姿勢がお前らが全く上達してない原因だと思う。
俺は間違った指摘に対して間違っていると言っただけだ。
Cの奴らがあくまで「技術的」なのとは対照的に、お前らは「精神的」な物言いばかりだ。
ある意味、やっていることが「Web的」だ。言ったもの勝ちみたいな馬鹿が多い。
とはいえ、間違っていることをいくら主張しても正しくはならない。
そもそもオブジェクトプールはインミュータブルの世界ではほぼ意味がない。
URLﾘﾝｸ(www.html5rocks.com)
そして俺はJIT向けの最適化をしようとはしていない。
事実、メモリをケチるとか、一度にアクセスするデータを纏めるとか、どの言語でも高速化する。
実際、>>279内URLも言語には言及されてない。
もちろんそれ以前に他の改修点も多い。今はそこを整理中だ。
とはいえ、その先の「将来的改修方法」まで見据える必要があるので確認中ということになる。
>>280
ところで、何でお前はそんなに認めて君なんだ？
俺の質問は「asm.jsでフットプリント削減/メモリ配置決めうちは出来るか」であって、
「asm.jsで局所的高速化が出来るか」ではない。
つまり、脱線しているだけだから素っ気ない回答になっているだけだ。
俺がやろうとしているのは、君が思っているasm.jsの使い方ではない。
282:デフォルトの名無しさん
16/06/29 20:10:31.16 oxwc/50g.net
自分の話なのに他人を非難し始めた！？
こりゃ重病や～
283:デフォルトの名無しさん
16/06/29 20:14:07.66 oxwc/50g.net
こいつの親はなんで
「相手がどう思うかが大事」
「自分が伝えたつもりでも相手に伝わってなかったら意味が無い」
って教えてやらなかったのかな……
むごいね。
284:デフォルトの名無しさん
16/06/30 01:34:38.72 YtNZP2Mq.net
ちなみに、当面の問題は解決した。
実はもっさりというよりはカクカクに近かったのだが、原因はキャッシュによるHDDアクセスの過剰だった。
ヘッダに cache-control: no-store を追加したところ、完全に治った。
ただそれでも(program)が70-90%であることには変わりないのだが、
スクレイピング中でも(idle)は80%以上なので、キビキビ感はある。
前にも書いたが、(>>109)
CPUだけで動く部分は実は相当速くて、UIが主なJavaScriptではCPUを使い切ることはないのかもしれない。
俺の場合はスクレイピングが律速過程なので、サーバの速度が上がらない限りここで頭打ちだ。
数値計算のように完全にCPUだけで回るのなら限界が見えるが、そういう用途はないし。
遅延描画は制御がやや面倒だが、実現してしまえばDOMは1画面分しか扱う必要がなく、一瞬で処理される。
俺のアプリに関して言えば、階層スクレイピングを行っているので、
下位階層を参照する時は更新されていることが確定している。
だから no-store で全く問題ないし、あと5倍の余裕があるので、残るは美学的問題だけになった。
ここを修正するかはしばらく様子見になる。
情報をくれた人はありがとう。
285:デフォルトの名無しさん
16/06/30 06:40:45.54 K37QNM6P.net
こういう自分用語多用・技術文書風自分語り・後出し情報でドヤ顔・他言語へのコンプレックスを持つ>>284を
スルーできないことこそ、お前らwが上達できない理由wだと思うよ
286:デフォルトの名無しさん
16/06/30 14:59:19.41 YdAxXmxA.net
普段スルーするようなキチガイでも無人島じゃコミュニケーション取るしかないのと同じ。
287:デフォルトの名無しさん
16/07/17 18:00:55.04 UzC9Qtsn.net
ｽﾚﾘﾝｸ(tech板:213番)
質問スレ>>213
自己紹介乙。
てかお前はどうしてそこにこだわるのか全く謎なのだが。
普通に考えれば、引き算が出来るのならMDNで、
> var elapsed = end.getTime() - start.getTime(); // 時間をミリ秒で表す
> URLﾘﾝｸ(developer.mozilla.org)
これは明らかにおかしくて、
var elapsed = end - start; // 時間をミリ秒で表す
となるべきだろ。お前が言う「経験のある」奴ならここに地雷臭をかぎ取るわけ。
何らかの理由で getTime() しないといけないんだよ。
とはいえ、今1stEdition(1997)見ても abstruct operator という単語自体は使ってないが、
他は同じなので、最初から出来たのではないかとも思うのだが、、、まあよく分からん。
URLﾘﾝｸ(www.ecma-international.org)
実際、彼がググって来た例でも直接引き算してないだろ。
俺が（当時）ググッた限りでも出てこなかったから、何かしら理由があるのだと思う。
というわけで俺は「使えない」判定を下していた。
で、これは多分「既に他言語を知っている奴」の普通のやり方なんだよ。
俺がお前に「経験がない」と断定しているのはこういうのが全く通じてないから。
何度も言っているが、お前はもっと書いた方がいい。
ここに質問に来る奴の大半は、「MDNを読め」で済む。
ただお前はもう教科書的な知識は十分にあるんだよ。
だから仕様書をいくら読んでもそれ以上にはならない。
お前が上達するには、書くしかないんだよ。
288:デフォルトの名無しさん
16/07/17 18:23:29.08 UzC9Qtsn.net
一応俺の疑問としては、
ToPrimitive(Number) は 無変換で Number そのものを返す。(9.1)
ToNumber(Number) は 無変換で Number そのものを返す。(9.3)
GetValue(V)はVが参照でなければ V そのものを返す。(8.7.1)
+ は ToPrimitive(GetValue(target))の型がStringならString連結、
そうでないなら ToNumber(ToPrimitive(GetValue(target))) で数値の和を返す。(11.6.1)
Date型は内部に time values を持ち、abstruct operationはこれを対象とする。(15.9.1)
だったら足し算も出来ないと駄目じゃね？ってことね。
厳密に言えばGetValueはabstruct operation ではないので、
仕様と実装に矛盾が無い為には、 GetValue(time values) がStringを返す必要がある。
こうなんだっけ？
289:デフォルトの名無しさん
16/07/17 18:30:48.46 PyzTEoPA.net
まだ43cmの深淵にはたどり着けないようだなｗ
290:デフォルトの名無しさん
16/07/17 18:40:03.90 UzC9Qtsn.net
>>289
いやそれ何の事よ？
誤爆かと思いきや、そうではないのなら、
とりあえずブラウザバグっているからリロードしとけ。
291:デフォルトの名無しさん
16/07/17 18:50:05.41 UzC9Qtsn.net
ああ、引き算を確認するの忘れてた。
- は ToNumber(GetValue(target)) を引いて差を返す (11.6.2)
ToNumber(String) は 9.3.1 に従いパースする (9.3)
9.3.1内にはDate.toString()出力をパースする仕様はない。
だからGetValue(time values)はNumberを返さないと引き算は出来ない。
となると足し算も出来ないと仕様外のように思える。
なお確認している仕様はECMA5.1
URLﾘﾝｸ(www.ecma-international.org)
292:デフォルトの名無しさん
16/07/17 18:54:57.34 PyzTEoPA.net
>>290
> いやそれ何の事よ？
布石だよｗ
俺は最初から正しいことを
言っていたと示すためのな。
293:デフォルトの名無しさん
16/07/17 18:55:32.09 PyzTEoPA.net
>>291
だから仕様通り（笑）
294:デフォルトの名無しさん
16/07/17 19:13:09.85 UzC9Qtsn.net
>>292
まあ何か思惑があるのならそれでいい。
ただ俺が見る限り今のところはAddが出来てもおかしくない仕様のように見える。
もちろん俺は仕様書なんてほぼ見てないから、先のように単語を変更されていると気づけないが。
まあいいや、とりあえず新着情報があるまではどうにもならんし。
現実的にDateが揃いも揃って仕様違反って事もないだろうし、
先の例のように俺が仕様書を読み慣れていないせいで見落としている部分があるのだろう。
295:デフォルトの名無しさん
16/07/17 19:23:49.21 UzC9Qtsn.net
> （今回で言えば日付型同士の減算が可能！？） (質問スレ>>213)
あと一応言っておくと、日付型ってのは普通は減算出来るんだよ。
だから質問者もいきなり減算しているし、
俺も逆にそれが出来ない！ってことでMDNに奇妙さを感じるわけでね。
だからこの点についても、この反応、もう一度書くと、
> （今回で言えば日付型同士の減算が可能！？） (質問スレ>>213)
これは経験豊富ならあり得ないんだよ。
で、そういうのは明らかにバレバレだから、
普通に考えてお前が経験豊富だと思う奴はいないと思うんだよね。
何でそこにこだわるのか全く分からないんだけど。
匿名掲示板で虚勢を張る意味無くね？ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
296:デフォルトの名無しさん
16/07/17 21:11:43.34 PyzTEoPA.net
>>295
何いってんのお前ｗ
MDNに日付の減算が出来ないなんて書いてないし
それなりにJavaScript使ってりゃ、
日付同士の引き算とかやるだろ。
ベンチマークとかでさ。
当たり前の知っていることなんだが？
お前にとっては当たり前じゃないんだろ？ｗ
297:デフォルトの名無しさん
16/07/17 21:12:34.25 PyzTEoPA.net
> 現実的にDateが揃いも揃って仕様違反って事もないだろうし、
だから最初から仕様通りって言ってる
298:デフォルトの名無しさん
16/07/17 22:11:41.91 UzC9Qtsn.net
つか相変わらずお前は都合が悪いところは読まない主義なのなw
MSDNでもやっぱりgetTime()してるんだよ。
URLﾘﾝｸ(msdn.microsoft.com)(v=vs.94).aspx
既に言ったがMDNも。
URLﾘﾝｸ(developer.mozilla.org)
ついでにStackOverflowでも軒並み。
URLﾘﾝｸ(stackoverflow.com)
URLﾘﾝｸ(stackoverflow.com)
URLﾘﾝｸ(stackoverflow.com)
基本的にDateオブジェクトの直接操作は誰もやってないから、何か理由はあるとは思うんだけどね。
それが何かは俺には分からない。
考えられるのは、オブジェクト指向的な「メソッド越しに全てやれ」なのか、
実装ありきで来ている為、実は「仕様的裏付けがない」のか。（将来的に使える保証がない）
いずれにしても、サンプルコードにそう記述しない理由があるのは確かなんだよ。
どっちにしたってここまで地雷臭だと公開するコードなら直接操作は止めたほうがいいとは思うが。
質問者は今動けばいい個人レベルのコードだろうから別に構わないとは思うけど。
299:デフォルトの名無しさん
16/07/17 23:04:02.72 PyzTEoPA.net
だからgetTime使ってるからって
そのまま使えないってことにはならないんだが。
馬鹿なのかな？