АО
За все время пользовался один раз глобальными переменными, когда при помощи TimerOutputs профилировал функции.
Size: a a a
2020 October 25
АО
Слишком широкое утверждение, во многих случаях это единственный вариант не переусложнять код (по крайней мере, в языках без мультиметодов)
:-)) так, две школы переменных :-))))
ВФ
Слишком широкое утверждение, во многих случаях это единственный вариант не переусложнять код (по крайней мере, в языках без мультиметодов)
Я согласен
АО
На самом деле все что написано с помощью глобальных переменных легко переписывается в локальные.
АО
Ну, если пользоваться чём-то вроде Unpack.jl
АО
Всё, что вам нужно, собираете в один большой контейнер и передаёте его в функцию.
ВФ
Это конечно, но не всегда тянуть переменные в параметры удобно. Надо уж сразу структуру создавать тогда.
АО
Можно Named Tuppe
VG
Всё, что вам нужно, собираете в один большой контейнер и передаёте его в функцию.
Тоже не выход, проблема действительно в разделении контекстов.
АО
В 1.5 добавили совершенно фантастический сахар для их создания
АО
using Unpack
N = 1
M = 100
eps = 1e-6
opts = (; N, M, eps)
function f(opts)
@unpack N, M = opts
return N * M
endАО
Этот код будет работать быстро, требует достаточно небольших манипуляций для распаковки и никаких глобальных переменных.
АО
Могу ошибаться, но вроде даже так можно написать
function f(; opts)
...
endАО
То есть если надо какую-то дополнительную переменную создать, добавляете ее инициализацию, добавляете ее через запятую в opts и вытаскиваете unpack в нужных функциях.
ВФ
АО
Только студентам этого конечно не обьяснить :-) выглядеть будет как магия.
VG
Не понимаю, чем это будет отличаться, если вместо NamedTuple использовать в структуру
Context, пусть даже с @kwdefВФ
Ну, кстати, да. Потеря контекста у студентов - это классика. Лучше сразу к правильному стилю приучать, а не переучивать потом.
На самом деле, студенты про глобальные переменные изначально уже осведомлены, и приходится прикладывать большие усилия, чтобы отучить использовать их вместо параметров функций :)
АО
Не понимаю, чем это будет отличаться, если вместо NamedTuple использовать в структуру
Context, пусть даже с @kwdefНичем, просто структуру немного сложнее делать: ей надо имя придумывать, писать больше, она плохо под Revise живет.