JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net (766ﾚｽ)
JavaScript情報交換所(プログラミング既習者専用） [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1449440793/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
8: デフォルトの名無しさん [sage] 2015/12/08(火) 09:13:19.90 ID:DJ+OQKIp >>7 10レス未満だと落ちるよ http://mevius.5ch.net/test/read.cgi/tech/1449440793/8
26: デフォルトの名無しさん [sage] 2015/12/19(土) 02:42:41.90 ID:BBkFE1FJ Array.from()を実装したとして、それがどこまでの範囲で使えるのかは「使う側が確認する必要がある」とする。 つまり、callで突っ込むのは勝手だが、ちゃんと動くかは「確認しろよ」ということだ。 その手の動作範囲を広げていくのは、YAGNIとかKISSとか言われるらしいが、大体無駄に終わる。 だからArray.fromの実装側は自分が使う最小限に留めて良く、間借り側が正常動作を保証しろと考える。 これはおそらくJavaScriptの思想とも合致している。 ArrayのメソッドはgetElementsByTagName等で返されるCollectionに対しても大体動作するが、 動作の保証はしていない。 つまり、間借り側(Collectionでcallする側）が正常動作を保証（確認）する必要がある。 クラスシステムの場合、実装してあれば確実に動作するし、実装していなければ動作はしない。（間借りも出来ない） JavaScriptの場合は、使えそうなら使ってねといういかにも曖昧な感じで、それでいいのか？という疑問はあるが、 上記のように、「バグってたらリロードでおk」ならこの方が色々楽なのは事実だ。 結局の所、出自が（というよりも今も大半の用途でも）チョロスクリプトなので、それ向けに仕様がチューニングされている。 これで大規模なプログラムを組むのがそもそも無理がある、ということなのだとは思う。 チョロスクリプトとして使う分には、なかなか面白い仕様だと思う。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/26
64: デフォルトの名無しさん [sage] 2016/03/28(月) 23:29:32.90 ID:JoYhD075 nodeスレより http://yosuke-furukawa.hatenablog.com/entry/2016/03/27/152500 http://mevius.5ch.net/test/read.cgi/tech/1449440793/64
126: デフォルトの名無しさん [sage] 2016/05/13(金) 22:12:02.90 ID:PxVJ9U+u > どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。 それはCの考え方だ。そして君はC/C++と連携するためにNodeを使っているのだから、君としてはそれで正しい。 ただ、「メモリ」を意識するのはJavaScriptじゃないんだよ。 だから、君はおそらくCの考え方に束縛されている。 というか、それだと君はJavaScriptを使えていない。 君だと、Rubyでは何故ただの数値ですらオブジェクトなのか説明できないだろ？ 例えばサーバーのログを解析するとして、grepで済むならそれでいいけど、 それ以上なら通常はPerl等が用いられる。 もちろんこれをCでやることは出来るけど、普通はやらない。 理由は簡単、Perlの方が楽だからだ。 それをどうしてもCでやれ、Perlはインストールしてねーとなると、ふざけるな！となるだろ。 JavaScriptも同じで、クライアントスクリプトという政治的要因が無ければ、 当たり前だがその言語を使うのが一番楽（適している）ところで使われる。 その状態においては、 > どうせちょっと高速化を意識するとTypedArrayをメモリに見立ててあれこれするようになる。 これが要求されることはほぼ無い。 というか、メモリアクセス速度が要求されるのなら、最初からC/C++で書け、でしかない。 実際にこれで高速化するのなら、本来Cで書けばいいだけのものをJavaScriptで書いてるだけだよ。 👀 Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) http://mevius.5ch.net/test/read.cgi/tech/1449440793/126
290: デフォルトの名無しさん [sage] 2016/07/17(日) 18:40:03.90 ID:UzC9Qtsn >>289 いやそれ何の事よ？ 誤爆かと思いきや、そうではないのなら、 とりあえずブラウザバグっているからリロードしとけ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/290
409: デフォルトの名無しさん [sage] 2016/08/23(火) 23:50:21.90 ID:fTj2N0cj >>407 > exeみたいな実行形式 Webアプリから起動出来なければこれは問題無いだろ。 > OSで特別な意味を表すシステムファイル等 要するにシンボリックリンク等で全部筒抜けになる場合だろ。 これも結局Webアプリ側はブラウザを通しての作成しか出来ないので、それを止めればいいだけ。 OS側からシンボリックリンクを貼ったり、exeを置くのは自由でいい。 Webアプリ側でexeを起動出来ず、シンボリックリンク等を作成出来なければいいだけ。 つまりファイルは「データ」としてしか扱えないという、実装するにも至極簡単な制限でしかない。 FileSystemAPIははっきり言って使う気がない仕様を策定してる。だったら策定しない方がマシ。 まあ策定してから捨てるというのがJavaScript流ではあるようだが。 > IndexedDBやCacheDBの存在で意義をなくしつつある。 結局の所、「勝手に削除される可能性がある」時点でアーカイブとしては使えない。 見たところここを保証する気はなさそうなので、 今回俺がこれらをメインに据えることは出来ないし、 どのみち「削除されない」ストレージも必要になると思う。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/409
663: デフォルトの名無しさん [sage] 2020/07/24(金) 09:35:52.90 ID:2LubhzPR >>658 > DOM APIの仕様だ まあ厳密にはあれはDOMに入れるべき物でもないんだよ。 だから今も「For web developers(non-nomative)」という中途半端な扱いになってる。 あれはDOMと言うよりはプログラミングモデルであって、本来は別仕様を起こすべきなのだが、 それを言いだしたらきりがないから現状はDOMに突っ込まれているだけでさ。 > 「イベントバブルを最初に実装した」というのはどういう意味か言ってみ > お前は「イベントがDOM要素の下位から上位へバブルのように登っていくこと」を実装した。 そうだぞ。俺はそう言ったんだ。 イベントがバブルするGUIフレームワークというのは、俺が知ってる中ではHTML/CSS/JavaScriptが初だよ。 それ以前の、XやMFC、.NET(Forms)ではバブルしない。 むしろお前は何をどう勘違いして俺に突っかかってきてるんだ？ >>659 お前が簡単に書けるのなら書かないよ。書く意味もないし。 それってconsoleログ知ってる俺スゲー的なレベルであって、そんなもん一々コード書いてても時間の無駄だろ。 >>660 そう思うのならそれでいいと思うが。 必死にjQueryにすがるからおかしくなるだけで。 必要ない人はjQueryを使わないし、実際必要なくなりつつあるだけの話で、必要だと思えば使い続ければいいし、それだけだろ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/663
667: デフォルトの名無しさん [sage] 2020/07/24(金) 09:42:35.90 ID:fMjVnhWI >>664 > なら逆に、「イベントバブルを利用するが親ではイベントを処理しない」方式で何か有効活用出来るか？ 英語のwikipediaにかいてある。 > それがあれば「大前提」ってのは俺の勘違いだと認めるが。 それがあったのでお前の勘違いだと認めるようにｗ http://mevius.5ch.net/test/read.cgi/tech/1449440793/667
669: デフォルトの名無しさん [sage] 2020/07/24(金) 09:48:58.90 ID:2LubhzPR >>665 wikiじゃねーかよ！そりゃ書いた奴が分かってねえんだよ。 既に言ったが、世の中のGUIフレームワークはイベントバブルをこぞって採用してる。 .NETはWPFから、GTKは3から。Qtは知らんが間違いなく採用はされるかその方向の筈。 理由も既に言ったとおり、バブルが出来れば非常に効率よくGUIを実装出来るから、 それに慣れると、バブルが出来ないフレームワークなんてゴミにしか見えなくなるから。 >>666-668 どうにもお前とは話が噛み合わないからこの辺で終わりにしておこう。 色々既に言ったとおりだ。気になるなら読み返してみてくれ。 http://mevius.5ch.net/test/read.cgi/tech/1449440793/669
687: デフォルトの名無しさん [sage] 2020/07/24(金) 10:52:08.90 ID:fMjVnhWI > 逆に、本当にこのケース「一つのイベントに複数のハンドラを持たせたい為」にバブルを利用して、 > それ以外の方法では美しく実装出来ないケースがあれば確かに俺の勘違いだと認めるが、あるか？ 一つのイベント・・・click それ以外の方法では美しく実装出来ないケース・・・google map お前の勘違いだって認めようねｗ http://mevius.5ch.net/test/read.cgi/tech/1449440793/687
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.037s