Vasiliy
Посмотрел разные выступления людей и там любят показывать пример:
если есть какой-нибудь enum, обозначающий состояние этого класса, то через DU можно их выразить так, чтобы не использовать enum. (и как раз используем компилятор в помощь, чтобы убрать бизнес ошибки)
Например, у меня есть вот такой енам:
public enum SessionStates
{
NotSet = 0,
Created = 1,
Delivery = 2,
ReadyToCreate = 3,
ContractCreated = 4,
SignInProgress = 5,
Signed = 6,
OnlineApp = 7,
Cancelled = 8,
Error = 9,
DboAgreed = 10,
ChildInfoSaved = 12,
}
был бы смысл делать из такого enum 12 разных рекордов с разными состояниями?
Vasily
Зачем?
IdiocyAcceptance
ChildInfoSaved = 12, - прикольное состояние
Vasiliy
ну да. там про DU
Ayrat
Vasiliy
Зачем?
чтобы как я понял, было бы такое
type Session =
| NotSetSession of
| CreatedSession of
| DeliverySession of
и т.д.
Vasiliy
ну и соответственно в коде можно будет использовать рекорды NotSetSession и т.п.
только вот где тот предел кол-ва типов что ли
Vasiliy
хотя с кол-вом 12 я бы сказал что это оверинжениинг
Pavel S
Зачем тут рекорды? DU чтоб компилер в матчинге точно знал что есть неприкрытый кэйс, с енумом он есть всегда
Denis
Зачем тут рекорды? DU чтоб компилер в матчинге точно знал что есть неприкрытый кэйс, с енумом он есть всегда
ну сторого гвооря сделав enum типа byte вполне можно покрыть все кейсы
Roman
чтобы как я понял, было бы такое
type Session =
| NotSetSession of
| CreatedSession of
| DeliverySession of
и т.д.
имеет смысл делать DU со вложенными данными, если данные для этих шагов отличаются. Например, на 6 шаге данных должно быть больше, чем на 5 и тд.
Если набор данных одинаковый, то можно обойтись DU без вложенных данных, который будет по сути как енум. В этом случае DU все равно лучше, т.к. у него по-честному ограниченное множество кейсов, и туда нельзя закастить рандомный инт
Vasiliy
о, норм. подумаю)
Stas
ChildInfoSaved = 12, - прикольное состояние
У меня как то была вложенная структура и был метод RemoveChildById()
Ilya
Пожалуй, даже если данные у кейсов ду не отличаются, можно будет указать конкретный кейс в сигнатуре функции и избавиться от проверки внутри. К тому же, при необходимости проще добавить новые данные конкретным состояниям.
Roman
Пожалуй, даже если данные у кейсов ду не отличаются, можно будет указать конкретный кейс в сигнатуре функции и избавиться от проверки внутри. К тому же, при необходимости проще добавить новые данные конкретным состояниям.
ну ты можешь либо запихать 1 раз DU в рекорд, либо n раз запихать рекорд в DU. Выбор за тобой!
Hog
Шалом, православные!
Hog
Chag Pesach Sameach!
Ilya
Уже таки Песах?
Hog
Завтра :)
Viacheslav
ну ты можешь либо запихать 1 раз DU в рекорд, либо n раз запихать рекорд в DU. Выбор за тобой!
Тогда вроде компилятор не сможет помочь
Vasiliy
ну ты можешь либо запихать 1 раз DU в рекорд, либо n раз запихать рекорд в DU. Выбор за тобой!
А как же идея сделать Неявное Явным?
Vasiliy
ну запихнуть 1 DU я могу и в c# классе
Viacheslav
Как это? Компилируется же! 🤣
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AbEAzAzmgFxAEsMAfCABxgDsACAZQE9cCYBbAWACgeCnqdACIBVOgF46AQTpk6AIR58BMOgCUYkKABMJdAN7CAriGEiA3HQCSp4jQJ0Avku4YYD7HSgSedP3XYAQwIwAAsvOgB3YgJQ3385QyEjPSlLKz1iJzo4AD46Sig7Amx6ACIAUikyr3i/ROM9eXTM7LyCovtSukrqryA
Не, всё ок, я чот думал, что он не сможет определить, что все кейсы сматчены
Roman
А как же идея сделать Неявное Явным?
А что тут неявного? Оба варианта выражают абсолютно одно и то же с одинаковой степенью гарантии. Только в одном случае ты напрямую используешь произведение типов (рекорд), а в другом сложение, и складываешь n раз подряд
Shub
Посмотрел разные выступления людей и там любят показывать пример:
если есть какой-нибудь enum, обозначающий состояние этого класса, то через DU можно их выразить так, чтобы не использовать enum. (и как раз используем компилятор в помощь, чтобы убрать бизнес ошибки)
Например, у меня есть вот такой енам:
public enum SessionStates
{
NotSet = 0,
Created = 1,
Delivery = 2,
ReadyToCreate = 3,
ContractCreated = 4,
SignInProgress = 5,
Signed = 6,
OnlineApp = 7,
Cancelled = 8,
Error = 9,
DboAgreed = 10,
ChildInfoSaved = 12,
}
был бы смысл делать из такого enum 12 разных рекордов с разными состояниями?
Согласно влашинцам только так и следует делать. ПОТОМУ ЧТО.
Сейчас мне достался проект на 10kloc, написанный в таком стиле и там тупо невозможно делать новые фичи. Но это даже не самое главное. Главное, что компилятор там нихера не «ловит ошибочные состояния», на проекте открыто порядка 50 багов касаемых именно состояний
Vasily
Джоба сама себя не засекурит
Shub
Зачем тут рекорды? DU чтоб компилер в матчинге точно знал что есть неприкрытый кэйс, с енумом он есть всегда
Ну конечно, ведь когда мы матчим по model.status – компилятор не знает, что есть незакрытые кейсы. Только если матчить по model. Фишка компилятора F# такая
Vasily
Дедушка сочится ядом
Vagif
Посмотрел разные выступления людей и там любят показывать пример:
если есть какой-нибудь enum, обозначающий состояние этого класса, то через DU можно их выразить так, чтобы не использовать enum. (и как раз используем компилятор в помощь, чтобы убрать бизнес ошибки)
Например, у меня есть вот такой енам:
public enum SessionStates
{
NotSet = 0,
Created = 1,
Delivery = 2,
ReadyToCreate = 3,
ContractCreated = 4,
SignInProgress = 5,
Signed = 6,
OnlineApp = 7,
Cancelled = 8,
Error = 9,
DboAgreed = 10,
ChildInfoSaved = 12,
}
был бы смысл делать из такого enum 12 разных рекордов с разными состояниями?
Необязательно 12 разных рекордов, но если, например, ContractCreated содержит в себе дату создания контракта, не вижу причин, почему бы это не выразить как ContractCreated of CreationDetails
Vagif
Но вообще говоря, важно понимать, как этот State используется.
Shub
Пожалуй, даже если данные у кейсов ду не отличаются, можно будет указать конкретный кейс в сигнатуре функции и избавиться от проверки внутри. К тому же, при необходимости проще добавить новые данные конкретным состояниям.
Тебе Родина актив паттерны дала. Матчи, блин, аргументы. Нет, не хочу матчить аргументы, хочу переписывать по пол-проекта раз в месяц
Vagif
Если по смыслу это именно enum для показа, в каком состоянии находится FSM, то не нужны никакие рекорды. Если же это само по сути состояние, то дополнительная информация нужна
Vagif
Ну и Active pattern is your friend, конечно. Мы вовсю их используем
Shub
Если по смыслу это именно enum для показа, в каком состоянии находится FSM, то не нужны никакие рекорды. Если же это само по сути состояние, то дополнительная информация нужна
ФСМ крайне херово реализуется на DU. В основном потому, что продукт никогда не специфицирует фсм полностью на 10 лет вперед. Поэтому каждый раз, когда продукт переосмысливает че-то там у себя, наши маленькие любители фсм носятся как угорелые, потому что фсм начинает работать против них самих
Shub
Единственное, чего добиваются сторонники «модель как DU” - это вытаскивание какого-то случайного поля-статуса на уровень выше. Очень смешно делается, когда таких статусов несколько, я прямо хохочу до упаду
Vasiliy
а, да тоже подумал сегодня, типо что делать если таких полей несколько
Vasiliy
а, да тоже подумал сегодня, типо что делать если таких полей несколько
но кажется это даже в обычном коде не очень хорошо будет.
Hog
И тут же побежал так писать?
Vasiliy
ха, было бы где так писать!
Hog
Мне чот сразу показалось, что там кода на порядки больше. И я забил
Shub
Make implicit explicit - это из zen of Python, т несет вполне конкретный смысл в том контексте. Я тебе гарантирую, что ни Влашин, ни миллионы его леммингов с этим смыслом не знакомы
Hog
А невозможные состояния пусть тестеры отлавливают
Hog
Это тоже Влашин? Там вроде было про невозможные неправильные состояния
Shub
Это тоже Влашин? Там вроде было про невозможные неправильные состояния
И это было, и это тоже в стиле «мне Рабинович немного напел Карузо - не понимаю, что люди в нем находят.
Shub
Illegal state unrepresentable - это статья Йарона Мински, состоящая из размахиваний руками более чем на 95%. Влашин взял лозунг на знамена и просто размахивает руками немножко иначе.
Vasiliy
никому не угодишь :D
Vasiliy
Ха, потом придут и скажут, что за гавно ты тут написал
Hog
@nigurrath у тебя сегодня выходной? :)
Shub
Ха, потом придут и скажут, что за гавно ты тут написал
Если в коде будет четко прослеживаться, почему ты так написал, а так же если код будет просто менять по новым требованиям - то не кажут
Shub
Нашел статью кстати, называется Effective ML revisited
Vagif
Единственное, чего добиваются сторонники «модель как DU” - это вытаскивание какого-то случайного поля-статуса на уровень выше. Очень смешно делается, когда таких статусов несколько, я прямо хохочу до упаду
Может и можно было бы с этим пояснее разобраться, но только не в таком стиле, да оно, тебе, наверное, и не нужно. Влашина убить, Симан мудак.
Shub
Может и можно было бы с этим пояснее разобраться, но только не в таком стиле, да оно, тебе, наверное, и не нужно. Влашина убить, Симан мудак.
Я человек совершенно другой культуры, мне чужд ваш скандинавский максимализм
Hog
Ой
Shub
Про Влашина и хорошие места его блога было сказано много и неоднократно. Влашин не виноват, что поколение твиттера не может вместить больше, чем книжечка на 150 страничек
Vagif
Illegal state unrepresentable - это статья Йарона Мински, состоящая из размахиваний руками более чем на 95%. Влашин взял лозунг на знамена и просто размахивает руками немножко иначе.
Мински многим прочистил мозги той статьей и продолжает чистить. Там нет никакого размахивания руками, а есть практический совет.
Shub
Мински многим прочистил мозги той статьей и продолжает чистить. Там нет никакого размахивания руками, а есть практический совет.
Ага. Только во второй статье у него написано ровно обратное тому, что пропагандирует Влашин. Так что не знаю, что он там кому чистил
Shub
Ну или может некоторым для очистки Геракл нужен
Ilya
Интересная дискуссия.
Vagif
IdiocyAcceptance
Мне кажется лучше чётко сформулировать свою точку зрения о "making illegal state unrepresentable" через призму F#, а то ответов, если честно, все эти обвинения не дают)
Vasiliy
интересно однако
https://t.me/theworldisnoteasy/1248
Vagif
Я просто вижу примеры конкретного дизайна, когда разработчики, ссылаясь на Мински (а многие приписывают эту цитату Влашину), убирают из своих типов option и nullable, делая модель более строгой и жесткой. Не совсем понимаю, что в этом может раздражать.
IdiocyAcceptance
Я просто вижу примеры конкретного дизайна, когда разработчики, ссылаясь на Мински (а многие приписывают эту цитату Влашину), убирают из своих типов option и nullable, делая модель более строгой и жесткой. Не совсем понимаю, что в этом может раздражать.
Разве в таком случае мало убрать option и nullable? А что насчёт PositiveInt, String50 и прочих решений?
Vagif
То есть несколько лет назад разработчик заводил один тип для RegisteredUser и UnregisteredUser, задавая в нем First/LastName как option. После прочтения этих блогов и книжек тот же разработчик заводит два типа, и в каждом заданы только обязательные поля. Налицо профит
Ilya
Vagif
Разве в таком случае мало убрать option и nullable? А что насчёт PositiveInt, String50 и прочих решений?
Я никогда не пользовался типами типа String50, мне задание подобных типов кажется неудачным решением
Vagif
Разве в таком случае мало убрать option и nullable? А что насчёт PositiveInt, String50 и прочих решений?
Против PositiveInt ничего против не имею