元スレ+ JavaScript の質問用スレッド vol.132 +

みんなの評価 :
351 = :
>>346
存在しない
もしも超絶ハイパー奇跡的に2050年とかまで仕様策定が続いたら
そのとき最後のバージョンとしてそれを出す可能性だけはある
352 = :
>>339
おお、忠告ありがとうっす。
確かに色々手を出しすぎるのは厳しいよねえ。
できるだけライブラリで済ませられるものはそれに頼って頑張ります。
353 = :
>>350
それはできればしたくないだろう
ES2015のときの話だが
だからまだましな解決策としてSymbol.unscopablesが導入されたが
それだけでは十分では無かった
だからもうimport "std:Array-Ex"みたいにやってくほうがベターかね
という雰囲気になって、しばらくそれ系の提案は勢いを潜めてるってことだ
物事はもっと複雑で、Web APIが返す配列がArrayを継承してくれる目処も経ってなかった頃だったしな
とりあえず、それ以上議論を攻めるような感じにはならなかったということ
354 = :
なら、Array拡張するモジュールを標準化すれば良いのでは?
デフォルトではArrayはそのまま、標準化された
ArrayExをimportすれば拡張される
まあいいや、
どちらにしろ
> 本当に良い機能でいっぱいなら仕様に取り込まれてそう
という意見は間違いで、良い機能でいっぱいであっても
仕様に取り込まれないことはよくある話ってことだよ
355 = :
良くわからんが相当癇に障ったらしい
356 = :
? 単に良いものなら取り入れられるっていうのは
考えが甘いって話をしてるだけだよ。
良くても取り入れられないものはたくさんあるのが現実
357 = :
>>354
標準化すれば良いのでは?って……
今まで説明した話を聞いていなかったのか?
標準モジュールの話が本腰入れてできるようになったのは、
ES2015後切り離して議論していたモジュールの構文以外の部分がようやくまとまって実装されだした今だし、
valuesもONにしたりOFFにしたり様子を見てたが、ONにしていって大丈夫だろうという判断が出た今からが
配列のメソッドに手を入れていくムードになり得るということだよ、物事には流れや雰囲気っていうのがあるんだからね
でも今はもう個別のメソッドが提案されてるし、やっぱりまとめてどっさりではなく1個1個入れていく形になるかもねってこと
それはそれで、そっちのほうが良いだろうよ
とりあえずRubyか何かを真似してどっさり持ってくるよりもさ
それでね、一番言いたかったのは、「お前が提案してこいよ!!いやしてください」ってことなんだけど
伝わらなかった?
358 = :
伝わらなかった?って俺がいつ標準化しろって言ったんだ?
標準化する方法はあるって話をしただけ
俺は良いものであっても標準化されるとは限らないって話をしてる
359 = :
>>358
俺は良いものであっても標準化されるとは限らないと言わずに
標準化されるように提案しようと言ってる
なぜなら「本当に良いもの」なんて個人次第だから
それを提案して皆に認められて仕様に入って実装されて初めて「本当に良いもの」と言えるんだよ
それには時期とタイミングっていうのがある
Rubyに入ってる「本当に良いもの」だから、今JSに入れても「本当に良いもの」になるというわけではない
JSが大きく関わっているWebの他の物や開発者、実装などの準備やタイミングもあるんだよ
だから、もし今その「本当に良いもの」が「本当に良いもの」になれると思うのなら提案すればいい
それぞれの言語の事情を踏まえないと他の言語を引き合いに出しても仕方がない
俺は、「本当に良いもの」はきちんと然るべきときに導入されてきてると思うよ
360 = :
お?喧嘩か?
361 = :
いや、喧嘩はする気はない、明日仕事6時からだし遠慮してくれ
362 = :
若いなら色々手を出したほうがいい
でも年取ってものいうのは専門性だから
すこしずつ絞っていくようにすればいい
どれを選ぶかは仕事でなにをやるかとかそういうもので決まっていくことが多い
プログラム以外の強い分野もも1つくらいつくようにするとなおよし
363 = :
素人の行き方には、根拠が無い。
C#が目標でも、C#からは行けない。そういう道がない。
Java から行かないと無理だろ
JavaScript(JS), Python にも、直接行く道がない。
素人は、行けると思うけど、漏れら、10言語以上知っていると、無理だとわかる
「たのしいRuby 第5版、2016」
これを読んで無理なら、それ以上進めない
JSなどは、オブジェクト指向・クラスじゃないだろ。
いきなりプロトタイプだから、JSの内部の実装を学んだ所で、何もならないし時間の無駄。
ビジネスロジックとは無関係
Rubyで、Sinatra を、full scratch で書く方が速い。
それがRails を作る事と同じ
「Node.js超入門、掌田津耶乃、2017」
この本を読めばわかるが、
Node.jsを、full scratch で書くと、Sinatra と同じ。
Node.js + Express + Bookshelf が、Rails と同じ
「10日でおぼえる jQuery 入門教室 第2版、山田祥寛(よしひろ)、2013」
この本が、RubyのNokogiri と同じ
最初から、JSで苦しむより、Rubyでフレームワークを学んでから、
Node.jsへ行った方が、ずっと速い
364 = :
今ではマルチパラダイムが主流だし
古典的なクラスに完全に縛られてるクラスベース言語も無くなってきてるんだから
プロトタイプベースのJSで、クラスとはオブジェクト指向に於ける抽象化プログラミングの一種だと
認識していたほうが、他の言語に言っても理解が早い
365 = :
>>359
ならお前が提案すれば良いんじゃねーの?
なんで良いものであっても標準化されるとは限らないよって
言ってるだけの俺に提案しろって言ってるのか意味不明なんだけど
366 = :
Rubyはオブジェクト指向を突き詰めるとの本末転倒ぷりを身をもって示してくれた、クソ原理主義言語。
rails以外に存在価値なし。
367 = :
>>365
✘良いものであっても標準化されるとは限らない
○俺が考える良いものであっても標準化されるとは限らない
368 = :
超初心者の質問をお願いします!
iOS safariで、ブラウザ閲覧中のスリープ時に何か処理を実行したいのですが
どのようにすればいいでしょうか?
visibilitychangeとhiddenでiOS以外のブラウザでは実行できるのですが。。。
よろしくお願い致します
370 = :
http://developer.mozilla.org/ja/docs/Web/Reference/Events/visibilitychange
これみるとIE phone以外対応してることになってるけど?
371 = :
やさしいRubyアニキとjQueryアニキはどっちが長男なの?
372 = :
スリープ時はタイマーも止まる可能性大だし、処理が継続できる保証もない
PCでスリープした時を考えると当たり前だと思うだろう
スリープ時になにかするという事は避けたほうが良い
373 = :
ブラウザ閲覧中のスリープ時
の意味がわからん
374 = :
タブ切替じゃないの?
376 = :
別タブなり別アプリなり開いてる間も処理し続けるとか、最初からそういうものでなきゃ「迷惑だからやめろ」って思うんだが……
378 = :
ライブラリ使うとそんなこともわからない人材ができあがるのか
ソース見てないけど
379 = :
裏でこっそりマイニングさせようとしてて
スリープとか別アプリとかされた時にサーバに通知させたい動機だったりして
380 = :
var a=[1,{b:true},3];
var b=a.concat();
b[2]=5;
a[1].b=false;
console.log(a);//[1,{b:false},3]
console.log(b);//[1,{b:false},5]
concatでシャローコピーしたつもりなのですが
a[2],b[2]は成功
しかし、a[1],b[1]のオブジェクトはどっちもfalseになっていて
干渉していました・・・
forで繰り返して構築する以外に
完璧なシャローコピー(?)をするにはどうしたらいいですか
381 = :
これはだめ?
b = JSON.parse(JSON.stringify(a))
382 = :
http://stackoverflow.com/questions/597588/how-do-you-clone-an-array-of-objects-in-javascript
ここにいろいろのっとる
383 = :
>>380
>シャロー
シャローではなくディープだろう
シャロー( shallow )は「浅い」
384 = :
http://qiita.com/knhr__/items/d7de463bf9013d5d3dc0
ここにもいろいろのっとる
385 = :
>>381
日付型とかが壊れる
391 = :
>>389
http://www.buildinsider.net/web/angularjstips/0038
お手本があったよ
392 = :
angularとか小洒落たもんつかってんな
393 = :
アドブロックブロックの原理ってどうなってんのあれ?
解除したいんだけど。
394 = :
・そのサイトを使うのをやめる
・そのサイトがアドブロックブロックやってることを宣伝拡散
395 = :
アドブロックブロック対策のために
検出不可能なアドブロックを作りたい
397 = :
>>395
今は要素を消したり隠したりを表のレイヤーでやるから感知されうるが
Houdini系APIを利用してレンダリングのレベルで調整すればバレにくくなる
ただそれでも今ではどうしても痕跡が残るが
もし拡張機能からより上位のレイヤーを調整できるようにさせてもらえれば可能かも
398 = :
>>397
完璧を目指すと最悪ブラウザ作ることにはなるんだろうなっては思ってる
あと要素を消したり隠したりするからバレるわけだよね。
それをやらなければいい。やり方はあって(というか昔やってた)
画像の場合は透明画像にすり替える。他の形式もそれぞれダミーにすり替える。
要素は消さない。ただ見えないだけ。
これだけで結構検出は難しくなると思うよ
あとはJavaScriptによる自動操作、HTMLを書き換えると検出されそうだから
ページが読み込んでるいずれかのJavaScriptファイルを書き換えて
匿名関数の即時実行で処理させる。またwindow.openなどの関数を
オーバーライドして処理を割り込ませる
アイデアは有るけどそれを拡張機能として作るのが面倒だなw
399 = :
あと拡張機能でHTTPプロキシみたいなことできるんだろうか?
できなければプロキシ作れば良いんだけどhttps対応がめんどいな
400 = :
逆の観点で言って、プロキシでフィルター通しても
画面に本来必要不可欠な処理と統合されたら対応不可能になるんじゃない?



類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.122 + (1004) - [97%] - 2015/2/14 4:45
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.142 + (984) - [97%] - 2020/8/27 19:15
- + JavaScript の質問用スレッド vol.112 + (1001) - [97%] - 2013/11/27 16:46
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.122 + (116) - [97%] - 2018/5/2 18:30
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.134 + (1001) - [97%] - 2018/8/3 23:15
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.142 + (926) - [97%] - 2019/12/23 13:15
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.102 + (1001) - [97%] - 2012/9/11 17:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
トップメニューへ / →のくす牧場書庫について