VA
Ну можно и не просто держать идею в уме, а применять с умом, например, избегая типов String50 для адреса, а заводя тип Address
Size: a a a
2021 April 14
VS
имеешь ввиду address который покрывает единственный примитив со стрингом с валидацией длины? ну это зависит от его переиспользуемости в кодобазе, если он просто всегда живет внутри другого объекта и в базу хоронится, я бы не создавал отдельный тип, а оставлял бы примитив или unit of measure. Валидация будет не на создании адреса, а на создании всего родительского объекта
I
При таком подходе ты не сможешь защищённо юзать рекорды те же
I
Что тогда помешает тебе сделать let data = { data with Address = "bullshit" }
VS
код ревью?) если адрес отдельно не используется, то такой код и не должен существовать
I
Ну, про код ревью это понятно) Вопрос же был построен иначе (на сколько я понял) - как на уровне системы типов и компилятора защититься от ошибок
VS
так в экстремуме это не работает, надо всегда искать золотую середину)
VS
по-моему это вообще путь фарша - "срединный"
VS
можно рекорды вообще не юзать, юзать классы с конструктором
VS
кстати мб есть пропоузал на то чтобы разрешит запрещать with рекордам
VS
а не, ерунду предложил) все равно можно рекорд невалидный создать всегда) да, класс с конструктором идеально подходит
VA
Unit of measure - тоже нормально и быстрее, но это уже детали реализации
VA
Не был бы так категоричен, но в целом имеет смысл бизнес-типы защищать.
P
А в чем проблема с string50? я не агитирую за него, мне просто всё ещё хочется понять мотивацию отрицания такого кейса..
VK
если сильно хочется то можно через UMX сделать, там хотя бы весь этот типовой мусор вырежет плюс минус
P
Влашин доносит простую понятную и хорошую идею - чтоб невалидные состояние были непредставимы. Что пытаются донести противники подхода? Кроме - не дела так, так плохо..
VK
а так это часто просто онанизм валидации
P
То есть мысль противников - не делать так слишком часто, доводя идею до абсурда? Если так, то ок