((
я даже был уверен что в js там будет какая-то дичь, а оказалось логично
Size: a a a
2020 July 03
T
я даже был уверен что в js там будет какая-то дичь, а оказалось логично
this
я уже прям ожидал что-то типа 1 2 1 2
я уже прям ожидал что-то типа 1 2 1 2
VL
я думал, 11 22 изначально
T
но поц чему?
VL
Мол, замыкание изолирует переменную на момент создания
T
не, референс только
VL
А оказалось Shared, да
MB
Мол, замыкание изолирует переменную на момент создания
А где это так работает?
MB
Вообще это одна из причин поменьше мутироваться, такие приколы сложно искать
OR
Мол, замыкание изолирует переменную на момент создания
Ну так оберни в IIFE
OR
А так там глобальная переменная, оба замыкания смотрят на неё.
VL
А где это так работает?
(defn foo []
(let [counter (atom 0)]
(fn [] (do (swap! counter inc) @counter))))
(def f1 (foo))
(def f2 (foo))
(comment
(f1)
(f2))
OR
Ну нет же
VL
да, counter надо вынести
MB
(defn foo []
(let [counter (atom 0)]
(fn [] (do (swap! counter inc) @counter))))
(def f1 (foo))
(def f2 (foo))
(comment
(f1)
(f2))
Если этот атом снаружи создать, то будет то же самое
VL
(def counter (atom 0))
(defn foo []
(fn [] (do (swap! counter inc) @counter)))
(def f1 (foo))
(def f2 (foo))
(comment
(f1)
(f2))
OR
Тот вопрос скорее на базовое знание замыканий, нежели на знание особенностей
OR
Никакого тебе hoisting или перекрытия областей видимости
MB
В общем, никакой магии не происходит, захватываемая переменная из тела функции просто ссылается на ту же память, что и переменная, которую она захватила