AL
обязан следить за порядком выполнения
Size: a a a
2020 October 07
E
обязан следить за порядком выполнения
с чего бы?
R
а вот в мутабельном сетапе например может быть так
fun mut() = { global var x = 0; x+=2; return x / 2; }
fun mut() = { global var x = 0; x+=2; return x / 2; }
А это сайд-эффекты. Которые так же неприлично делать в нормальном ООП
AL
да с того бы.
mut() + mut() - mut() имеет значениеDT
Evgen
с чего бы?
С того что ты не можешь предсказать что вернёт mut()?
a
не имеет значения в иммутабельном сетапе
иммутабельно порядок вызовов тоже может иметь значение
let value = 3;
value = addIfLess10(value, 3)
value = addIfLessr10(value, 7)
// value is 13
let value = 3;
value = addIfLess10(value, 7)
value = addIfLess10(value, 3)
// value is 10
AL
А это сайд-эффекты. Которые так же неприлично делать в нормальном ООП
ну так значит в нормальном ООП нет места мутабельности?
DT
А это сайд-эффекты. Которые так же неприлично делать в нормальном ООП
Ну вот. Ты понял почему иммутабельность важно)
DE
ну так значит в нормальном ООП нет места мутабельности?
Верно. Но хейтеры ООП в каждой статье пишут про мутабельный шаред стейт.
E
да с того бы.
mut() + mut() - mut() имеет значениену и как будет отличаться не иммутабельный код от этого?
R
Ну нет. Вы сейчас говорите "объекты нельзя менять". Я говорю "чужие объекты нельзя менять". Если юзеру нужно в текущей функции поменять емейл — он поменяется, хоть это будет в пределах того же объекта, хоть это будет новый. То есть, концептуально я не вижу разницы между:
и
user = getUser();
print(user.getEmail()); // hello@hello
newUser = user.changeEmail(newEmail);
print(newUser.getEmail()); // world@world
user = getUser();
print(user.getEmail()); // hello@hello
user.changeEmail(newEmail);
print(user.getEmail()); // world@world
и
user = getUser();
print(user.getEmail()); // hello@hello
newUser = user.changeEmail(newEmail);
print(newUser.getEmail()); // world@world
R
При этом, в последнем есть риск использовать старый и неактуальный объект юзера, у которого будет неактуальный email
AL
Evgen
ну и как будет отличаться не иммутабельный код от этого?
а никак. в иммутабельном коде, просто невозможно иметь функцию mut в таком виде.
она будет выглядеть примерно так:
т.е. вся суть в том, что ты получаешь контекст на вход вы выдаешь новый на выходе.
она будет выглядеть примерно так:
data class Context(val x: Int = 0)
fun Context.mut(): Pair<Int, Context> {
Pair(x / 2, Context(x + 2))
}
т.е. вся суть в том, что ты получаешь контекст на вход вы выдаешь новый на выходе.
AL
таким образом твоя функция внутри ничего не "запоминает"
AL
но хочу сказать, что я не фанатик лепить во всех местах иммутабельные функции.
и например можно всегда сделать красивую приватную функцию
и например можно всегда сделать красивую приватную функцию
DE
Верно. Но хейтеры ООП в каждой статье пишут про мутабельный шаред стейт.
Чем и вызывают подозрения, что они не осилили нормальный ООП, где глобального мутабельного стейта вообще-то нет.
E
а никак. в иммутабельном коде, просто невозможно иметь функцию mut в таком виде.
она будет выглядеть примерно так:
т.е. вся суть в том, что ты получаешь контекст на вход вы выдаешь новый на выходе.
она будет выглядеть примерно так:
data class Context(val x: Int = 0)
fun Context.mut(): Pair<Int, Context> {
Pair(x / 2, Context(x + 2))
}
т.е. вся суть в том, что ты получаешь контекст на вход вы выдаешь новый на выходе.
Тогда почему вы говорите что где-то важен порядок вызова, а где-то не важен если сравнивать вам не с чем
AL
Evgen
Тогда почему вы говорите что где-то важен порядок вызова, а где-то не важен если сравнивать вам не с чем
еще раз говорю. в иммутабельном коде, такой функции просто невозможно сделать.
в этом вся и суть
в этом вся и суть
E
еще раз говорю. в иммутабельном коде, такой функции просто невозможно сделать.
в этом вся и суть
в этом вся и суть
Тогда утверждение о порядке вызова функции заведомо ложное
AL
нет, в иммутабельном коде порядок выполнения функций внутри другой функции не имеет значения