ŹR
Все ещё не понятно, как работают переменные в области видимости
Size: a a a
2020 May 27
ŹR
Есть в репле область видимости
ŹR
Или нет?
AR
я когда "работаю с реплом" я не в консольку ввожу обычно код. в консольке если поиграться / поинтроспектить что-то
AR
я файлики редактирую, а репл сам код релоадить с учетом графа зависимостей
AR
и редактор к этому же реплу подключен
ŹR
Ну возвращаясь к примеру - скачал юзера из базы чтобы с ним поиграть - где этот юзер хранится?
ŹR
А если ты поменял структуру класса - что с ним станет?
AR
классов нет, но про что ты говоришь? ну если ты записал что-то в БД, то оно там и осталось конечно
ŹR
Всмысле нету классов? Это же Jvm, не?
AR
ну в жвм классы, но это типа деталь имлементации, в целом какая разница как байткод выглядит?
AR
в beam внутри тоже мб что-то классом называется
ŹR
Смысл в структуре, которая может поменяться при изменении кода, при условии что стейт остаётся
ŹR
Я что, в репле не могу в промежуточную переменную ничего засунуть?
ŹR
Типа user = database.download(user,1)
ŹR
А потом описание типа поменял у этого user
AR
любая штука, которая содержит стейт прямо или опосредованно (через использование другой стейтфул штуки) экплицитно объявляется через DI систему, содержит как минимум start "метод", опционально еще и stop/pause/resume
AR
когда ты апдейтишь код репл сначала паузит/стопает все стейтфул компоненты, потом релоадит код согласно графу (релоадит все зависимые от измененного неймспейс), потом резьюмит компоненты опять
AR
делает конечно топологически отсортировав компоненты по зависимостям
ŹR
когда ты апдейтишь код репл сначала паузит/стопает все стейтфул компоненты, потом релоадит код согласно графу (релоадит все зависимые от измененного неймспейс), потом резьюмит компоненты опять
Ну вот было user с name, а ты поле name удалил в коде, он что, не сдохнет чтоли?