Во-первых, валидация с атрибутом [Required] абсолютно никак не связаны с ключевым словом required. У них разные предназначения.
"убедиться, что клиент предоставит значение для обозначенного поля" - это ближе к атрибуту. А ключевое слово нужно исключительно при создании экземпляров класса, причем именно через new. (Поддержка разными десериализаторами этого ключевого слова и соответствующее [Required]-like поведение является исключительно следствием появления самого required, но никак не наоборот).
вы так эмоционально не понимаете, будто я вас убеждаю отказаться от использования
У меня скорее складывается подозрение, что у вас ошибочное представление о том, что такое required и зачем он нужен.
Была мысль использовать его шире, убрав инициализацию в null not nullable fields and properties, но это требовало менять инициализацию в куче мест.
Вот например здесь. Если вы действительно хотели ввести ключевое слово required, то, во-первых, вам не понадобилось бы никаких null, а, во-вторых, его легко ввести во все нужные поля даже при наличии существующих конструкторов. И даже на этом этапе от него уже пойдёт определённая польза!
Поэтому либо у вас сильно искажено понимание этого ключевого слова, либо мы вообще говорим о разных языках программирования.
Все еще непонятно, причем тут какая-то валидация. Ключевое слово required вообще с ней никак не связано.
Хлопоты, про которые я говорил - накладываемые ограничения, типа конструктора без параметров.
Но ведь с required конструктор всё еще запросто может быть без параметров. Что я не так понял в вашем сообщении?
Мы хотели убрать null! инициализацию для not nullable properties, но оказались не готовы для этого менять логику.
Снова непонятно. Вы осознанно поощряете отсутствие инициализации некоторых полей, но введение required, которое вам бы прогарантировало исправление данной ситуации, вы называете "не готовы менять логику" — т.е. по факту не готовы вручную проинициализировать все пропущенные поля, и сиё утверждение считаете достаточным аргументом против required? Всё так понял, или я снова затупил?
А мы наоборот, используем в своих DTO его по максимуму. Польза: мы всегда уверены, что все нужные поля будут проинициализировано любым пользователем DTO. Хлопот никаких нет. А какие они у вас?
Громко не соглашусь. Вы вот в своей статье почему-то даже не написали для чего, собственно, нужно это ключевое слово. Только как оно работает. Вы также не обосновали это ваше утверждение, хотя оно мелькнуло минимум дважды за статью.
А я вот поделюсь своим личным мнением, для чего оно нужно. На мой взгляд, его единственная цель - это не дать забыть про инициализацию этого поля разработчиком, который пишет new().
В этом случае как тип, так и nullability поля не имеет значения. На разработчика накладывается обязательство explicitly (-over implicitly) указать изначальное значение, даже если оно null/default.
Таким образом чтение кода сильно упрощается - в будущем любому читающему не будет непонятно, писатель кода забыл указать значение, или же оно там действительно должно быть проинициализировано значением "null".
Это как то умаляет высказываемые в ней мысли? Даже доказанное лицемерие ещё не делает тебя лгуном.
Простите, но мне стало еще непонятнее.
Во-первых, валидация с атрибутом
[Required]абсолютно никак не связаны с ключевым словомrequired. У них разные предназначения."убедиться, что клиент предоставит значение для обозначенного поля" - это ближе к атрибуту. А ключевое слово нужно исключительно при создании экземпляров класса, причем именно через
new. (Поддержка разными десериализаторами этого ключевого слова и соответствующее [Required]-like поведение является исключительно следствием появления самогоrequired, но никак не наоборот).У меня скорее складывается подозрение, что у вас ошибочное представление о том, что такое
requiredи зачем он нужен.Вот например здесь. Если вы действительно хотели ввести ключевое слово
required, то, во-первых, вам не понадобилось бы никакихnull, а, во-вторых, его легко ввести во все нужные поля даже при наличии существующих конструкторов. И даже на этом этапе от него уже пойдёт определённая польза!Поэтому либо у вас сильно искажено понимание этого ключевого слова, либо мы вообще говорим о разных языках программирования.
Все еще непонятно, причем тут какая-то валидация. Ключевое слово
requiredвообще с ней никак не связано.Но ведь с
requiredконструктор всё еще запросто может быть без параметров. Что я не так понял в вашем сообщении?Снова непонятно. Вы осознанно поощряете отсутствие инициализации некоторых полей, но введение
required, которое вам бы прогарантировало исправление данной ситуации, вы называете "не готовы менять логику" — т.е. по факту не готовы вручную проинициализировать все пропущенные поля, и сиё утверждение считаете достаточным аргументом противrequired? Всё так понял, или я снова затупил?Простите, а причем тут валидация? Речь про
required, не[Required].Я же русским по темному написал обоснование необходимости и как именно это поможет, аж в двух местах.
А мы наоборот, используем в своих DTO его по максимуму. Польза: мы всегда уверены, что все нужные поля будут проинициализировано любым пользователем DTO. Хлопот никаких нет. А какие они у вас?
Громко не соглашусь. Вы вот в своей статье почему-то даже не написали для чего, собственно, нужно это ключевое слово. Только как оно работает. Вы также не обосновали это ваше утверждение, хотя оно мелькнуло минимум дважды за статью.
А я вот поделюсь своим личным мнением, для чего оно нужно. На мой взгляд, его единственная цель - это не дать забыть про инициализацию этого поля разработчиком, который пишет new().
В этом случае как тип, так и nullability поля не имеет значения. На разработчика накладывается обязательство explicitly (-over implicitly) указать изначальное значение, даже если оно null/default.
Таким образом чтение кода сильно упрощается - в будущем любому читающему не будет непонятно, писатель кода забыл указать значение, или же оно там действительно должно быть проинициализировано значением "null".
А водителя в случае смертельного ДТП тоже можно перекомпилировать или отменить через ctrl-z?
Им пора делать Lite версию
Там помимо этого ещё миллион UX проблем, которых нет с телеге
Нет, браузер лучше оптимизирует память
Пфф божечки. Git gud
И почему же они перестают работать?
Только на рынке дичайшая нехватка, поэтому никто безработным не становится
Которая не у всех провайдеров одинаково работает
Эдакими путями мы придем к подсветке Visual Studio 2019 Color Theme ^^
У меня ощущение, что его необходимость как будто бы очевидна.
Для остальных это как обычный смеситель и термостатный. "Не нужно нам это ваше удобство!"
У меня лицензия.
Я уж молчу про синхронное обновление списка дисков в моем компьютере.