P
тоесть ты создавал две, вместо них создал одну, они выполнились один раз, она ж одна, точно так же и с не-ленивыми
Size: a a a
2020 March 05
DS
посмотрел ещё раз, не понял, чем отличается от не-ленивых
В случае такого рефакторинга не ленивых ты теряешь поведение, потому что вместов вывода
"BOOM"
"BOOM"
в консоль ты получишь только "BOOM".
В случае рефакторинга ленивых ты в обоих случаях получишь:
"BOOM"
"BOOM"
Т.е. поведение полностью сохранилось после такого рефакторинга
"BOOM"
"BOOM"
в консоль ты получишь только "BOOM".
В случае рефакторинга ленивых ты в обоих случаях получишь:
"BOOM"
"BOOM"
Т.е. поведение полностью сохранилось после такого рефакторинга
P
В случае такого рефакторинга не ленивых ты теряешь поведение, потому что вместов вывода
"BOOM"
"BOOM"
в консоль ты получишь только "BOOM".
В случае рефакторинга ленивых ты в обоих случаях получишь:
"BOOM"
"BOOM"
Т.е. поведение полностью сохранилось после такого рефакторинга
"BOOM"
"BOOM"
в консоль ты получишь только "BOOM".
В случае рефакторинга ленивых ты в обоих случаях получишь:
"BOOM"
"BOOM"
Т.е. поведение полностью сохранилось после такого рефакторинга
тоесть это ничем не отличается от лямбды?
DS
тоесть это ничем не отличается от лямбды?
Ну только у тебя все по умолчнию футуры обернуты в лямбду.
P
Ну только у тебя все по умолчнию футуры обернуты в лямбду.
Future<T>::get такая же лямбда, как и () -> T
P
тоесть я могу future.get(), а могу future::get
P
и на месте первого я могу класть объект, а на месте второго -- любую () -> T
P
тоесть, если мне надо будет читать лениво -- я возьму лямбду, если не-лениво -- возьму фьючу и начну исполнять до того, как мне понадобится значение
P
при этом можно это абстрагировать до одного интерфейса -- Callable<T> throws Exception, или Supplier<T> если нужен Infallable
DF
Чё тут. В итоге пришли к тому что ленивые футуры это просто функции ?
P
Dollar Føølish
Чё тут. В итоге пришли к тому что ленивые футуры это просто функции ?
как всегда, да
p
Разница в том, что если десугарить эту запись как было тобой предложено, то программы в ней не будут ссылочно прозрачны, как ты и указал в примере выше.
А если десугарить по второму варианту, то это свойство будет сохранятся, т.е. есть ли мы заменим read_line_io на возвращаемое значение, то получим:
Что сохранит нужное нам поведение
А если десугарить по второму варианту, то это свойство будет сохранятся, т.е. есть ли мы заменим read_line_io на возвращаемое значение, то получим:
(lambda _: получение из консоли строки).bind(lambda a: a + "\n")
Что сохранит нужное нам поведение
то есть ссылочная прозрачность ради ссылочной прозрачности?
p
Вот пример этого я прям выше и кидал:
https://imgur.com/S19Nr4a.png
Вот тут Future - это не ленивый таск, который запускается сразу.
Из-за этого мы можем получить проблемы даже при малейших изменениях кода, как в примерах, или поведение с неявно непредсказуемым порядком действий.
https://imgur.com/S19Nr4a.png
Вот тут Future - это не ленивый таск, который запускается сразу.
Из-за этого мы можем получить проблемы даже при малейших изменениях кода, как в примерах, или поведение с неявно непредсказуемым порядком действий.
сначала всегда должно быть fa, затем fb
DS
тоесть, если мне надо будет читать лениво -- я возьму лямбду, если не-лениво -- возьму фьючу и начну исполнять до того, как мне понадобится значение
Ну пробема в том, что если совмещать ленивые и не ленивые футуры, то преимущества ленивых теряются.
Ты уже не можешь смело рефакторить код не включая мозг, т.к. можешь испортить при рефакторинге изначальное поведение даже небольшими правками.
Ты уже не можешь смело рефакторить код не включая мозг, т.к. можешь испортить при рефакторинге изначальное поведение даже небольшими правками.
P
Ну пробема в том, что если совмещать ленивые и не ленивые футуры, то преимущества ленивых теряются.
Ты уже не можешь смело рефакторить код не включая мозг, т.к. можешь испортить при рефакторинге изначальное поведение даже небольшими правками.
Ты уже не можешь смело рефакторить код не включая мозг, т.к. можешь испортить при рефакторинге изначальное поведение даже небольшими правками.
так если у тебя код должен выполняться каждый раз -- зачем его заворачивать в футуру?
P
это как бы собственная характеристика "функции" она либо функция как есть и её можно при желании выполнять асинхронно, либо она футура -- кешированный результат
DS
так если у тебя код должен выполняться каждый раз -- зачем его заворачивать в футуру?
Футуры возникнут везде, где есть Input/Output, конкурентность, параллельность или мутабельный между тредами стейт.
DS
В других местах можно и не заворачивать.
P
Футуры возникнут везде, где есть Input/Output, конкурентность, параллельность или мутабельный между тредами стейт.
почему?
DS
почему?
Потому что если эти вещи как-то не оборачивать, то теряется ссылочная прозрачность всей программы.
Т.к. это побочные эффекты, вызов которых вне обертке приводит к потери программой хороших свойств
Т.к. это побочные эффекты, вызов которых вне обертке приводит к потери программой хороших свойств