>>400
ふつうのfunction関数もアロー関数もスコープは関数スコープとブロックスコープを作るよ。
だから作るスコープの観点では、両者に違いはない。
もし、function関数とアロー関数に構文以上の違いは無いんですかという質問だったなら話は別だが。

>>401
スコープは一緒なんですか
クラスのメソッドでthis使う時
アローだと関数内で使えてfunctionだとnot definedなるのはなぜですか？

>>402
意味が分からないのならthisを使うな
http://blog.uhy.ooo/entry/2020-05-30/this/

ｗｗ

>>402
勘違いしがちだけどthisは変数じゃないんだよ
なので変数のスコープと並べて考えちゃいかん

実際むしろ逆で
thisを持つスコープともたないスコープがあるんだが
いきなりそこから理解するのも難しいと思うので

とりあえず最初は、大雑把ですまんが
スコープや状況に応じてバインドされるものが変わるもの
程度に考えてみるのがいいかもしれない

そんでthisを使い倒して理解できた気になったら
改めてECMA Scriptの仕様書を読むと
より深く理解できると思う

>>406
function f() {
console.log('this in f:', this);
}
function g() {
'use strict';
console.log('this in g:', this);
}
f(); //=> this in f: グローバルオブジェクト ( ブラウザ環境なら window )
(0, f)(); //=> this in f: グローバルオブジェクト ( ブラウザ環境なら window )
g(); //=> 'this in g: undefined
(0, g)(); //=> 'this in g: undefined
var obj = {f, g};
obj.f(); //=> this in f: obj
(0, obj.f)(); //=> this in f: グローバルオブジェクト ( ブラウザ環境なら window )
obj.g(); //=> 'this in g: obj
(0, obj.g)(); //=> 'this in g: undefined

ガンマ演算子の神業。

カンマ演算子ってminifyしたコードではよく使われてるけど
自分で意識して使ったことなかったわ

値として観測されると重ね合わせが壊れて情報が失われるってことでしょ？

>>409
横からだが勉強になった

>>409
疑問に思ったのはそこじゃなかったんだが勉強になった

ただthisのbindingを知るという目的だと
コールサイトでのレシーバの有無だけで十分理解できるので
ちょっと実装の詳細に入り込みすぎてる気もした

You don’t know JSでthisのbindルールが
以下の4ルールでまとめられてて個人的にはわかりやすかったかな
1. new binding
2. implicit binding (called with context)
3. explicit binding (call/apply)
4. default binding (global/undefined)

pythonのメソッド記述方式が正解だったか…

pythonは他のいろんな使いづらい点が多いからな

可能な限りthisを使わないのが正解

めんどうだからといって避けていてよいのだろうか？

Ruby は一々、self を渡さなくても良いように、実装で頑張った

JavaScript のthis は、window を指したりする場合があるなど、ややこしいから、
jQuery, Haxe などでは、this の挙動が変えられた

>>418
that = this とかやってるレガシーなコードに触るときくらい
それ以外はclassの中くらいにしておいた方が良い
初心者は特に

>>419
>>413 のようにケースベースで覚えようとするから理解できない
仕様ベースで覚えれば簡単に理解できる

ブラックジョークならぬJSジョークw

むしろ内部仕様を理解しようとせずパターンで覚えようと言う方が無理がある

> functionと書いた場合、第ゼロ引数とでも呼ばれるものがあると考えればいい
> つまり function foo(this, a, b, c)

どういうことかと言うと

function foo(this, a, b, c) {
　　$(element).on('click', function(this, event) {
　　　　// thisはなにか？
　　});
}

こういうこと。この書き方でthisが何かというと、そりゃ
呼び出し元が渡したオブジェクトに決まってるだろ？
引数にあるんだから当たり前。渡す方は自由にthisの内容を変えて渡せる

一方、アロー関数はfunctionがないのだからthisは存在しない

function foo(this, a, b, c) {
　　$(element).on('click', event => { } );
}

その場合のthisはfoo関数に渡されたthisに決まってるだろ？
こういう話。thisは全てこれで説明できる。

内部の実装とか仕様とか考えてないで、一番単純な方法で理解しよう

こうやってthisは引数で呼び出し側が渡す値って理解すれば、
Javaなどの言語とJavaScriptはthisが全く同じであることが理解できる
違うのはthisではなく呼び出し側なんだよ。


function foo(this, a, b, c) { } という関数をJavaScriptで呼び出す場合
一般的には obj.foo(a, b, c) という呼び出し方をする。

このfooのドットの左側、これがthisとして渡される。
これはJavaなどでも同じなんだよ

な？thisの仕様は同じだろ？


違いはJavaScriptは。obj.foo だけではなく obj.call や obj.apply で
thisを変更して呼び出す方法があるってこと

未経験からバックエンドエンジニアは無理で、フロントエンドからやるべきなんですか？

>>426
板違い
プログラム板じゃなくてプログラマ板にでも行け
http://medaka.5ch.net/prog/

jqおじさんの理解の仕方じゃすぐバグるな

thisは呼び出し元が渡すと言うのは良い解釈
実際の所は関数呼び出し時にthisArgが何になるかはReference値に依存していて
呼び出し方や呼び出し元などが本質的に結びついているわけではないが、
Reference値を壊さずに関数呼び出しを行う形は限られてくるので
superなど一部を除いて実際コード上の位置関係と形で考えることができる

thisが難しいのは状況によって何がthisとして渡されるかが様々に変化するってところだからな

>>424,425の説明は
何がthisとして渡されるのかは理解してるけれど
アロー関数のthisが理解できませんという激レアさん以外に意味あるのかな

>>424
なぜ、アローの方が簡単なのか良くわかる、素晴らしい説明！

JavaScript の場合、非同期処理をよく使うから、
上の方は、外側・内側の関数のコンテキストが異なることが多い

だから、this が鬼門

jQuery は、that = this みたいに書いてるけど、これが分かりやすい

かといってthisを説明するのに
さらに分からないReference値なるものを
定義も示さず連呼するのに比べれば
わかりやすく説明しようという努力の分だけマシだと思う

自分が分からないことを自分で勉強しようとしない人にはこのスレは向かないね

物事をわかりやすく説明できるのはその本質を理解してる人だけ

説明がわかりにくい人はその物事を真には理解していない

って言うけど違うよね。
それで分かったつもりになっちゃって僕は原子炉に詳しいんだ爆発だしｗ

分かりやすく説明できる <- 説明能力
物事をものすごく理解していても説明能力に欠ければ分かりやすい説明はできない
例えばすーぱーぷろぐらまー（宇宙人）が宇宙語で人間にがんばって説明しても理解されない
辞は達するのみ

そして相手がチンパン並みの理解力ならいくら分かりやすい説明しても無駄
結局は双方のバランスが大事

Referenceについて述べている >>409は丁寧に概要を説明してるし
>>429は質問に対する回答をしているわけじゃないでしょ

>>432の言うように単に連呼してる人なんて実際にはいない
ただ自分がこれだけの説明を聞いても理解できないし、かと言って調べるのも面倒で
その苛立ちから横槍を入れているようにしか見えない

自分が聞きたいことがあるならそれを素直に質問すれば>>409とかが教えてくれるだろうに
なんで回答者が自分から聞かれてないことまで解説しないといけないのさ?
ここは自ら学ぶ為のスレだよ?

>>437
そんなにイライラしなくてもw

知らない人に対して、知らない人が知らないであろう言葉で説明するのは未熟者
自分がちゃんと理解してないから説明できない

そうした説明では相手に本当に理解させることはできない。
仮に相対性理論をゴルフで説明できたところで、相手は木星まで光速の70%で行って戻ってきたときの時間の遅れを計算できるようにはならない。理解したつもりにさせられてるだけだからだ。
こんなものは詐欺師のテクニックや催眠術みたいなもの。
そうして僕は原子力に詳しいんだ爆発が起きる。
知ったか量産の害悪でしかない。

相手に本当に理解させる必要なんてないからね

技術者は正確性を重要視するあまり聞き手にとって不要な詳細を語りたがる
相手を見て情報の取捨選択が出来ない
常に実装の詳細がダダ漏れの設計と同じ

でもQiitaのワイの記事はいつもお世話になってるで

>>440
相手に本当に理解させることは目的ではない
なぜいきなり100点を取らせようとするのか

そうした説明では相手に本当に理解させることはできない。
そういって数学とは何たるかを小学一年生に語るのであった。

「泥団子と泥団子を合わせるとひとつの泥団子になるだろ？だから１足す１は１なんだ！」

>>441
逆に詳細を聞きたがる人もそれなりにいるよね

話しても良いけど
理解できる知識と経験ないでしょ？と思う

!
(
<
)

間違い探しの答えは5箇所！

>>448
そうですね！

x+yとa+bが等しい場合に前者のif節は実行されるが後者のif節は実行されない。
if( !( x+y<=a+b ))とif( x+y>a+b )または
if( !( x+y<a+b ))とif( x+y>=a+b )なら、
論理的には同じ。