【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
非同期の方法がたくさんあるからビルトインにしてないんだろ RxJSが使いたい→redux-observable generaterが使いたい→redux-saga Promiseが使いたい→redux-promise 好きなのを選べる rxは嫌いな奴は本当に嫌いなのでデフォルトにすると人死にが出る ReactとRx同時に使ったら、サイズが大きいのが気になりませんか? >>421 かなり慎重だったよ 当初提案のメソッドや機能も大分削ぎ落とされたし Rxってコンセプトがシンプルなのにいざ使おうとするとライブラリのインターフェースは複雑で、シンドってならない? >>428 でも結局Observableになるんだろ? Fetch APIがPromiseベースなので、処理がキャンセルできなくて困ったしな。 Fetch APIの戻り値はObservableに変更すべき。 >>429 jQueryとPromise(Deffered)で関数型インターフェースには慣れていたから、 イベントでフィルタできる新しいメソッドが追加されたぐらいにしか思ってないよw >>430 おいおい大丈夫か?? PromiseはPromiseで、ObservableはObservableで必要だよ いいか? ObがあればPrが要らないと言うのは ジェネレーター関数があれば関数が要らないと言ってるのと同じことだぞ 関数とジェネレータ関数の関係とはちょっと違う気がするが まあ言いたいことはわかる >>433 説得力ゼロだなw ObservableがあればPromiseはいらない。 ObservableにPromiseの機能が含まれてるから promiseは単発、observableは連発 連発は単発を包含してるが最適とは限らない completeしか発生しないObservable = Promise そもそも非同期=時間がかかる処理なのだから、 必然的に途中でキャンセルしたくなるのが普通。 キャンセルができない時点でPromiseは片手落ち >>436 promiseは非同期処理の約束手形observableはオブジェクトの値の変化を検知する仕組み。 なんでどっちかしかいらないって話になるのか >>438 Netflixとかなら動画を取り扱うからキャンセルできたほうがいいけど、 他の案件でも必要か?適材適所でしょう。 なんでもストリームとして取り扱うRxは宣言的な記述になるけど、 それが読みやすいかというと、 俺はpromise とasync awaitの方が読みやすい。 RxのObservableと廃案になったObject.observeが混在してる件 多機能があれば単機能はいらない そんなふうに思って(ry >>441 えっ。違うのかそれ。解ってなかった。すまぬ RxのObservableはnodeのReadable Stream (flowing mode) みたいなもん >>443 分かってなかったのかw 通りで話が噛み合わないわけか。 ObservableはPromiseの改良版 >>445 違う。Promiseで十分と思えるような作業であっても 実際は、処理のキャンセルや進捗状況の把握が必要になる。 だからPromiseの仕様では不十分という話 必要になるとは限らない そもそもキャンセルの方法がないものも多い promiseでは全てのケースをカバーできない→正しい だからpromiseはいらない→間違い でもPromiseだからこそasync awaitを駆使して同期プログラミングっポイ見た目でかけるわけで。 そこはRxではむりでしょ?そもそも宣言的な記述なウリなんだろうけども。 まぁ結局一人で開発だったらドッチもあってもいいけど 複数人プロジェクトだとRxは使いづらいわな。 Observeを束ねて全部処理が終わったら終了処理をしたいんだけど、どうやったらいいんだろう Httpリクエスト…Promise websocket…Observable んでRx使ったやつで良いプロジェクトってあるの? RxSwift使ってたときは良いプロジェクトが見当たらなくて 汚い設計になってしまった。 要る要らないは個人の考えや開発スタイルによるものだしなぁ つうかキャンセルだけならCancelablePromise案もあるし、 実際はキャンセルが内蔵されていると不都合があるのでCancelToken案のように 仕組みを外部に用意するのがベストだからPromiseは今のままで良いと思うよ あと因みに例で挙がってたfetchはキャンセル出来る。 キャンセルする必要があるような重たいファイルをDLするときは Stream使うだろうから、その場合rs側にcancelメソッドがある。 逆に言うと、もしfetchがプロミスレベルでキャンセルに対応した場合、 こういうStream何かとの兼ね合いはどうするのかって話になる。 自動でrs.cancelが呼ばれるようにするのか、それともclosed例外吐くようにするのか。 やっぱりCancelTokenのように外側から突き刺す形が一番良いよ。 なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた >>449 promiseでは全てのケースをカバーできない→正しい だからpromiseはいらない→そんなこと言ってない Observableでpromiseのケースをカバーできる→正しい だからpromiseはいらない→こう言っている >>460 > なんかの勉強会でcancelable promiseの標準化は頓挫したと聞いた そしてObservableの標準化が進んでいる promiseで十分なケースでわざわざobservable使うメリットあんのかよ >>464 promiseとobservableはインターフェースが違うから互換性がない。 だからライブラリを作るならば両方に対応しなければならない。 またtoPromise()などでobservableからPromiseに変更するなんて 面倒なことをしなければならない場合もある。 promiseとobservableの両方に対応しなくて良いのがメリットだ >>465 は? それならobservableなんて対応しなけりゃいいだけじゃねーか なんで両方に対応しなきゃいけねーんだよ >>467 殆どの要件でcancelは必要だから結局Fetch APIみたいに cancelするための別の仕様が出てくる。 だから最初からobservable一本にしておけばいいという話 急ぎすぎてPromiseを標準化してしまったのは黒歴史 Promiseを使ったFetch APIも黒歴史 >>468 fetchのことしか考えてねーのかよ fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ fetchが黒歴史なのは正しい promiseじゃなくstreamだろってsubstackも突っ込んでた > fsの非同期apiはキャンセル不可だがこれobservableにする意味あんのかよ あると思うけど? 俺は200MBを超えるファイル×数十個を "並列で" サーバーに送信したことがあるのだが、 もしメモリに全部読み込んでいたら、マシンによってはメモリ不足になっただろう。 だから特定のチャンクごとに読み込んで送信していたわけだが、当然キャンセルもしたいし どのファイルが何%処理完了したかの状況も表示したくなる。 そんときはループを使って、チャンクごとにデータを読み取って処理したわけだが、 もしfsがobservableであれば、メモリに全部読み取ることなく 一定のチャンクごとに処理する簡単な方法も提供されただろう。 setTimeoutなんかもclearTimeoutみたいにキャンセルするメソッドがあるし、 時間がかかるからこそ非同期にしているわけで、時間がかかる処理を キャンセルしたいことがありえないなんてAPIが本当にあるのだろうか? >>470 それはnodeじゃ昔からstreamでやってるやつだがその話じゃねーよ 今のnodeではcallbsckを取るfs.fstatとかの話だ >>472 俺が話をしているのはブラウザ版だ nodeの話はしてねーよw >>471 時間がかかる処理をキャンセルじゃなくて、待つのをキャンセルするじゃね? >>477 それは言い方の違いでしかないよ nodeでcallbackを使うやつの話であれば、そもそもなんで nodeはPromiseを使わなかったのか?の話になるだろ。 それはcallbackを使う方が速いのと、 何度もイベントを発生する必要があるものがあるからだろうな。 つまり、Promiseでは要件に耐えられないから Promiseではなくcallbackを使ったんだよ。 fs.fstatでは何度もイベントが発生するわけじゃなくても、 何度もイベントが発生することが可能なcallbackを使っている。 それは一度しかイベントが発生しなくてもPromiseではなく Observableを使ってよいのと同じ考えだ。 >>478 promiseの仕様がいつできたかも知らないのかよ nodeはその前からあるんだよ スレ違い野郎は消えろ http://stackoverflow.com/questions/30299613/why-does-nodejs-not-use-promise-for-the-readfile-api Node’s early iterations used Promises in its nonblocking API. However, in February 2010, Ryan Dahl made the decision to switch to the now-familiar callback(err, results...) format, on the grounds that Promises are a higher-level construct that belongs in “userland.” 英語わかるか? Nodeは最初Promise使っていて、callbackに変えたって書いてあるんだぞ (JavaScriptの)Promiseはいつできたんだっけな? 前に調べたんだが忘れたな。 ここを見る限り2009年なのは間違いないが。 http://wiki.commonjs.org/index.php?title=Promises& ;oldid=516 そのpromiseはes6のpromiseとは別物だ nodeでobservableに相当するのはstream fs.fstatはstreamを使わない それが答え 以上 >>482 それは当たり前だが、Promiseを捨てた理由は同じだ >>483 fs.fstatはPromiseを使わない。 それが答えだろう?w > nodeでobservableに相当するのはstream ちなみに、streamを知らない人に説明しておくと、 streamが使ってるのはPromiseではなくcallback >>484 promiseを使わない理由がキャンセルできないからじゃないのは分かってんのかよ システムコールレベルでキャンセルする方法がないのにobservableにするメリットあんのかって問いに答えてねーだろ nodeは単発にcallback、連発にstreamで使い分けてる 大は小を兼ねるとは限らないんだよ システムコールレベルって何の話? Win32APIとかレベルの話してるの? 独自用語で話すんなよ 何やこいつ キャンセルする必要がない単発はPromiseでいいし、キャンセルが必要か連発ならobs使えばいいって話だろ しゅうきょーせんそーかな? 単発だからってキャンセルする必要が無いことにはならないんだが? 言ってる意味わかる? Observableが得意なのはキャンセルだけじゃなくて 並列処理もなんで、fs.fstatを並列で実行したいときにも 簡単にかけるというメリットも有るな いくら君らが言い合っても、現実はかわらないでしょ? 今ある仕様がすべてで文句かるなら他の言語つかいなよで終わる話しじゃないの? 生産性のない答えもない事で争って暇すぎるだろ >>490 「キャンセルする必要がない場合は」 よく嫁 こいつもしかしてIT速報の管理人か? 転載禁止やぞ。対立煽りはNG スプーンとお玉の関係に似てる。 ジャムをすくうのにお玉を使ったら逆に不便だろ。そこは適切にスプーンを使え。 キャンセル処理がPromiseだと絶対無理というわけでもないし、Rxが必要とも思えないプロジェクトで無理やりRxを使う必要もない。 >>493 > 「キャンセルする必要がない場合は」 それはまずないだろうねw レスの文体からして前からJSスレに常駐してる荒らしでしょ コピペブログ管理人もやってたのかは知らんが >>487 システムコールってwikipediaにもエントリあるのに unix/linux系はダメなwindows君か どうりでダメなわけだ >>498 分かってないなw なんでシステムコールの話がでてくるんだってことだよ。 nodeのAPIと、OSのシステムコールを 一対一で直接結びつける必要はないっつーの nodeのAPIは単純な一命令でも、内部の実装は 何回もシステムコール呼んだって良いわけだ。 それが分かってないから、お前はシステムコールが キャンセルできるかどうかなんて言い出したんだろ こっちは全部お見通しだってーの fetchはキャンセルできる必要があるが、 fetchの戻り値をObsevableにするのは駄目。 Obsevableって一様な幾つものデータを受け取るのに向いているので fetchのように幾つかの段階で全然違うものが帰って来るのには向いていない。 単純に、Responseにabortメソッドを付けるのが良いと思う 勿論途中のStreamをObsevableにするのはとても良いと思うけど、 それを含んだ全体をするのはおかしい。 というか考えたら分かると思う。 キャンセルしたいのはfetchではなく、DLなのだから。 やっぱりCancelToken以外の解は無いと思うよ。 > キャンセルしたいのはfetchではなく、DLなのだから。 fetchはデータ送信もするんだが? その場合キャンセルしたいのは何だよ >>500 > 単純に、Responseにabortメソッドを付けるのが良いと思う fetchの戻り値はpromiseであってresponseではない。 responseはpromiseのthenの時に渡される。 promiseのthenが呼び出されるのはfetchの処理が完了した後。 つまりresponseを取得したとき=fetchし終わった時に abortするのは遅すぎる >>499 なにを見通してるのかさっぱり分からんがnodeは低水準のapiを提供するものだ そうすれば複数のシステムコールを組み合わせた高水準apiはユーザーレベルのライブラリで実現できる だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない >>505 > nodeは低水準のapiを提供するものだ どこにそんなことが書いてあるのか? nodeの立場はブラウザと同じだ。 JavaScriptの実行環境だ。 お前の理屈だと、ブラウザは低水準のAPIを提供するものということになる。 >>505 > だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない じゃあ、例えば、fs.lstatSync は posixのどの薄いラッパーなのか言ってみ >>506 > 仕様にはstreamが追加されてる どっちみち仕様を加えるなら Observableにした方がいいだろうな。 しかもPOSIXは非同期I/Oをキャンセルする機能あるじゃんwww https://linuxjm.osdn.jp/html/LDP_man-pages/man3/aio_cancel.3.html aio_cancel - 完了していない非同期 I/O リクエストをキャンセルする POSIX.1-2001, POSIX.1-2008. >>507 https://nodejs.org/api/fs.html File I/O is provided by simple wrappers around standard POSIX functions. >>508 lstat >>510 posix aioはほとんどのosで実装されてないしnodeでもサポートしてない >>510 細かく言うとposix aioはほとんどのos kernelで実装されてない gnuがユーザーレベルのライブラリとして実装したものがあるだけ manだとlstat(2)に対して>>510 のaio_xxx(3)なのでシステムコールじゃないことが分かる >>504 fetch apiが返すpromiseはfetchが完了してからresolveするわけではない 完了してからresolveするのはres.text()が返すpromise >>514 >>508 のlstatSyncは非同期じゃない >>515 > fetch apiが返すpromiseはfetchが完了してからresolveするわけではない 完了してからだよ。正確にはレスポンスが返ってきてから、 データの受信が完全に完了してからではない。 でないと、Response.statusが取れるわけがないだろう? >>518 それではシステムコールにあるPromise相当のものは何?w >>519 そう、だから完了してからじゃないじゃん 最初のチャンクが届いたらresolveする 「fetchの処理が完了した後」は明らかな間違い >>520 システムコールにはない 単にワーカースレッドでlstat呼ぶだけ >>521 Fetchの処理はリクエスト投げてレスポンス戻すところまでだよ。 ダウンロードが終了するまでの話は最初からしてない で、Fetchのキャンセル(thenが発動する前)はPromiseでできるの? できないでしょ? そこに新しい仕様が必要ならObservableを使えば良いわけさ。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる