Я более того скажу - зачем ВООБЩЕ нужен этот архаичный Startup? Он же сильно нарушает очевидность своей же работы, т.к. работает без контракта.
Нет, понятно, что контракт есть, но не в файле интерфейса, а где-то в дебрях MSDN-ов. Где-то там, в обычных текстах в интернете, находятся нужные сигнатуры методов. Но к чему этот головняк, если весь его функционал полностью доступен и через обычные методы, с очевидными прямо в коде сигнатурами?
Эти UseStartup<> тянутся из древности уже не один десяток лет, а интерфейс (да хоть бы и через generic constraint) к нему так толком и не прикрутили. При этом его использую очень много людей, практически повсеместно. Зачем?
Ну логично, ведь изза какого-нибудь runtime условия переменную могут как подменить, так и нет. Вам же не нужна потенциальная runtime ошибка, когда её можно подсветить уже на этапе компиляции?)
Можно допилить, сделав необязательным соблюдение порядка вызова методов у `VideoProcessingSettings`. Всяко автору библиотеки виднее, какой порядок более правильный, чем пользователю.
Ну, есть еще другая тема - у человека яркость (как и громкость) воспринимается нелинейно, а скорее логарифмически. Поэтому, кстати, многие аудиоплееры имеют логарифмический регулятор громкости. А AIMP, например, имеет настройку, позволяющую выбирать между этими двумя режимами..
А что не так с вашим "утрированием"? nullable позволяет выбросить наконец надоевшую валидацию по всему коду, бесконечные Guard.NotNull и прочие NRE на продуктиве.
Добавляется не пара процентов, а все 100% гарантии отсутствия null/NRE при условии, что вы этот nullable, конечно же, умеете готовить.
Я просто очень много видел людей, которые вставляют восклицательный знак то тут то там, а потом кричат, что nullable — фигня полная.
Практика "never null" хороша в попытке решить вышеуказанные проблемы (когда нет альтернативы в виде nullable context), но лишает возможности использовать null как инструмент в принципе, а это уже минус. Доп. минусом сюда идёт в комплекте то, что любой рандомный разраб всегда может случайно вернуть этот null куда не следует, и всё, считай, на смарку. Только потом еще есть шанс не найти этого места.
Речь о том, что во-первых, иметь какой-то буфер, который параллельно основному потоку бизнес-кода отправляет лог в сеть - плохо, т.к. падение процесса приводит к потере лога, и, во-вторых, иметь блокирующие методы логирования в сеть тоже плохо, т.к. потоки будут постоянно простаивать.
Я более того скажу - зачем ВООБЩЕ нужен этот архаичный Startup? Он же сильно нарушает очевидность своей же работы, т.к. работает без контракта.
Нет, понятно, что контракт есть, но не в файле интерфейса, а где-то в дебрях MSDN-ов. Где-то там, в обычных текстах в интернете, находятся нужные сигнатуры методов. Но к чему этот головняк, если весь его функционал полностью доступен и через обычные методы, с очевидными прямо в коде сигнатурами?
Эти
UseStartup<>тянутся из древности уже не один десяток лет, а интерфейс (да хоть бы и через generic constraint) к нему так толком и не прикрутили. При этом его использую очень много людей, практически повсеместно. Зачем?Работает до первого резонного "зависит от чего?".
Ну логично, ведь изза какого-нибудь runtime условия переменную могут как подменить, так и нет. Вам же не нужна потенциальная runtime ошибка, когда её можно подсветить уже на этапе компиляции?)
Можно допилить, сделав необязательным соблюдение порядка вызова методов у `VideoProcessingSettings`. Всяко автору библиотеки виднее, какой порядок более правильный, чем пользователю.
Спасибо за идею с конденсатором.
А смысл их продавать и покупать-то? Что за подозрительные операции?
Это было самым ожидаемой, и тем не менее, все равно очень крутой возможностью.
Штош, давно пора! (я сам моноколёсник).
Похожу на рекламу... Плохо чтоль?
Автору 15? Обалдеть, красавчик тогда. Я в 15 сделал полноценный мультиплеер, но дальше локалхоста ничего никуда не умел выкладывать и делать.
Ну, есть еще другая тема - у человека яркость (как и громкость) воспринимается нелинейно, а скорее логарифмически. Поэтому, кстати, многие аудиоплееры имеют логарифмический регулятор громкости. А AIMP, например, имеет настройку, позволяющую выбирать между этими двумя режимами..
Ну, т.е. всё вышеуказанное в принципе лечится обычным `#nullable enable`?
А что не так с вашим "утрированием"? nullable позволяет выбросить наконец надоевшую валидацию по всему коду, бесконечные
Guard.NotNullи прочие NRE на продуктиве.Добавляется не пара процентов, а все 100% гарантии отсутствия
null/NRE при условии, что вы этот nullable, конечно же, умеете готовить.Я просто очень много видел людей, которые вставляют восклицательный знак то тут то там, а потом кричат, что nullable — фигня полная.
Практика "never null" хороша в попытке решить вышеуказанные проблемы (когда нет альтернативы в виде nullable context), но лишает возможности использовать null как инструмент в принципе, а это уже минус. Доп. минусом сюда идёт в комплекте то, что любой рандомный разраб всегда может случайно вернуть этот
nullкуда не следует, и всё, считай, на смарку. Только потом еще есть шанс не найти этого места.Вряд ли маленькие дети могут лазать по стенам на высоте 2-3х метров
Странно, как будто без каких-то там статистик по запросам эта "реакция" сейчас такая супер положительная, лучи добра источающая.
А что с некоторыми ясно-то?
Всегда прикуривал и меня прикуривали. Аккумы также работали 5+ лет.
Решает/решать вышеуказанные проблемы.
Речь о том, что во-первых, иметь какой-то буфер, который параллельно основному потоку бизнес-кода отправляет лог в сеть - плохо, т.к. падение процесса приводит к потере лога, и, во-вторых, иметь блокирующие методы логирования в сеть тоже плохо, т.к. потоки будут постоянно простаивать.
Очень надеюсь, что своей синхронностью, если вы понимаете о чем я.