Size: a a a

2020 May 15

AV

Alexander Vershilov in fprog_spb
Но это уже близко к грани - "такое уже не нужно"
источник

AV

Alexander Vershilov in fprog_spb
Я не уверен, что мне удалось ответить на вопросы, но может хоть какое-то направление мысли показал
источник

AS

Alex Shipilov in fprog_spb
Пока я понял, что типы это вариант жесткой валидации, если на вход пришло не то, падаем, что это контракт между разработчиками, о том что «я на вход буду слать тебе такие то данные» и собственно контракт между функциями, чтобы строить глубокие цепочки(это мое предположение) с уверенностью, что на выходе у меня будет определенный тип
источник

AV

Alexander Vershilov in fprog_spb
> Пока я понял, что типы это вариант жесткой валидации, если на вход пришло не то, падаем,
> то падаем
источник

AV

Alexander Vershilov in fprog_spb
Не совсем так
источник

n

neFormal in fprog_spb
Alex Shipilov
Например в вебе, я получаю данные, обрабатываю, кладу в базу, по запросу дергаю, отдаю юзеру и в случае кложи это как правило мапа или массив мап и на входе и на выходе и даже в базе. Есть валидация на входе, которая отсекает не валидные данные, есть тесты, есть аннотации типов, но это скорее как помощь компилятору, а не обязанность. Теперь вопрос, где в этом потоке требуются типы и что они дают/какую ценность добавляют, и чем приходиться за это платить?
Обычно, типы заменяют валидацию. Заплатить придётся более строгим форматом и иногда дополнительными геттерами для гетерогенных коллекций
В остальных задачах этого конвейера разница не так заметна
источник

AV

Alexander Vershilov in fprog_spb
Это гарантия того, что тебе не придёт на вход не то, а не придёт оно потому, что тот, кто тебе это даёт проверит и гаранитирует, что это то, что нужно и решит, что делать если это не так
источник

AV

Alexander Vershilov in fprog_spb
Типы потребуют от тебя сделать валиадацию - да
источник

n

neFormal in fprog_spb
neFormal
Обычно, типы заменяют валидацию. Заплатить придётся более строгим форматом и иногда дополнительными геттерами для гетерогенных коллекций
В остальных задачах этого конвейера разница не так заметна
То же самое при работе с бд
источник

AV

Alexander Vershilov in fprog_spb
Это если мы говорим про типы объектов
источник

AV

Alexander Vershilov in fprog_spb
Ещё можно поговорить про типы вычислительных контекстов, про которые любят говорить хаскелисты
источник

YS

Yan Shkurinskiy in fprog_spb
не надо(
источник

n

neFormal in fprog_spb
Можно вспомнить о скорости
источник

AV

Alexander Vershilov in fprog_spb
Например хочется тебе гаратинировать, что эта функция, которая выполняет транзакцию не пойдёт делать запрос в сеть, который зависнет на полчаса по TLS timeout  и не залочит тебе полбазы.
источник

AV

Alexander Vershilov in fprog_spb
Или что функция не делает никаких побочных эффектов, а значит её можно сколько угодно раз перезапускать
источник

AV

Alexander Vershilov in fprog_spb
На основе 2го построен STM (один из механизмов межпроцесного взаимодействия в haskell)
источник

AV

Alexander Vershilov in fprog_spb
Или тот же atomic swap в IORef
источник

AV

Alexander Vershilov in fprog_spb
И здесь можно идти разными путями, вот @graninas любит свой подход, в котором (упрощенно) ты в одном месте можешь описать все внешние эффекты, которые может делать твой код, и в другом использовать. В этом случае ты можешь точно знать, что может делать, а что не может делать функция. И контролировать это
источник

AV

Alexander Vershilov in fprog_spb
Например добавить определенным функциям логирование (прям изкоробки между каждыми действиям) или заменить на моки или подсунуть другую реализацию
источник

AV

Alexander Vershilov in fprog_spb
При этом контроль есть не только над самими функциями, это в любом DI решении есть, а над последовательностью операций
источник