Думаю, что развитие программирования идёт эволюционным путём. Как существуют различные царства живых существ, так и различные подходы к программированию.
Каждый подход имеет свои преимущества и недостатки, которые делают его более оптимальным или неоптимальным для тех либо иных задач. Равно как в определённых условиях одни виды жизни более успешны, чем другие, а в других условиях — наоборот.
Конечно, я обычный человек, который может ошибаться, но над архитектурой редактора размышлял очень много времени. Это не единственный возможный вариант, но он мне очень даже нравится.
Хотите меня в чём-то переубедить, напишите-ка простенький текстовый редактор с аналогичным функционалом. И не забудьте про полное сохранение логического и визуального состояния при перезапуске приложения…
А потом сравните количество и читаемость получившегося кода. Получится лучше — поделитесь с сообществом своими наработками и видением. )
Я воспринимаю это иначе. В любой сфере есть этапы становления и развития, можно досчить определённого уровня, остановиться на нём и чувствовать себя вполне счастливым человеком. А можно активно искать и пробовать в данном направлении что-то новое дальше и дальше, изобретать, фантазировать… Понятно, что такой путь не для всех, но мне он близок. А вы лучше меня знаете, что для вас ближе. :)
Это пишет человек, которому только что было все равно на четырехкратное изменение?
Для вас пишу, ведь это вы так волнуетесь о производительности. Мне достаточно и того факта, что методы-расширения по порядку величин сопоставимы с нативной реализацией. А в 4 или в 1.2 раза отличие для меня не критично, это не в 100 раз и даже не в 10.
(x as T) ?? fallback. Только вы в вашей перегрузке делаете сначала is, а потом каст, так что ни о какой производительности речи и вовсе нет.
Если честно, я не сравнивал производительность именно этого метода с нативной реализацией (да и нативная реализация не поддерживает fallbackValue), но не думаю, что различия будут более чем в десятки раз. Если вы исследуете декомпиляции нативного PM, то увидите, что в разных сценариях он раскладывается в конструкции анологичные перегрузкам метода Is.
… а они более обобщенные? В них уже можно делать паттерн-матчинг? Они взаимозаменяемы с switch...case с идентичным синтаксисом?
Уже можно делать много интересных вещей, просмотрите примеры кода, связанные с Matching.
Затем, что завтра MS возьмет и сделает оптимизацию для этого синтаксического сахара, благо это тривиально. А ваши методы где были, там и останутся.
Почему раньше не сделали? Конечно, там умные люди работают, но вся система в целом иногда выдаёт странные и спорные решения. Поэтому не стоит слепо доверять даже авторитетам, а лучше всё переосмысливать самому.
Да, программирование с неизменяемым состояние имеет свои плюсы, но и свою ограниченную область применения. Для интерфесной логики, которой я по большей части и занимаюсь, этот подход плохо применим. Поэтому не стоит слепо предоваться модным веяниям и тенденциям.
«Видимого размера» — это лишь вершина айсберга, намного важнее, что привносит определённая структура кода в язык, к каким решениям неявно поддталкивает программистов.
Конечно, было бы здорово получить синтаксический сахар на нативном уровне вроде
но это вопросы к разработчикая языка. Я вносил подобные предложения, но дизайнеры уже приняли ряд весьма неоднозначных реший, первое из которых уже в релизе
IModel GetModel() => ...
/* true|false */
GetModel() is IModel m
/* always true */
GetModel() is var m
Далее предполагаются
/* true|false */
GetModel() is {} m // null check
/* true|false */
GetModel() is {Name is {} s, City is var c} m
не знаю, как для вас, но для меня более очевидны такие формы
/* true|false */
GetModel().Is(out var m) // null check
/* true|false */
GetModel().Is(out var m) && m.Check
(
m.Name.Is(out var s), // null check
m.City.To(out var c).Put(true)
).All(true)
Если перефразировать ваше утверждение в терминах программирования, учитывая порядок величин, то получится что-то вроде
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте цистерну!
-Без проблем! Начинайте капать..."
Да и если здраво подойти к вопросу, то
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте стакан!
-Стакан стоит столько-то центов..."
Знаете, ваша позиция напоминает мне такую: «Эти интегралы слишком сложные, нужно приложить усилия, чтобы научиться их читать и понимать, лучше я буду пользоваться школьной математикой». )
Откроется диалог сохранения файлов, а при нажатии на «Ок» вызовется «File.WriteAllText». Если документ будет пустой, то возникнет и обработается исключение ArgumentNullException «contents is empty», в ином случае сохранится, если других исключений не будет.
Ошибки (исключения) не игнорируются, вы можете в этом убедиться сами, запустив приложение.
В первую очередь я отталкиваюсь от логики самой программы, сейчас она функционирует отлично.
Главной вью-модели вообще ни к чему знать об исключениях, возникающих в работе докуметов, там произойти может, что угодно: нет доступа к файлу, формат не тот… Пускай документы сами разбираются, что с этим делать. Задача руководителя лишь создавать их и закрывать, когда нужно, попутно уведомляя о загрузке, закрытии и сохранении.
Каждый подход имеет свои преимущества и недостатки, которые делают его более оптимальным или неоптимальным для тех либо иных задач. Равно как в определённых условиях одни виды жизни более успешны, чем другие, а в других условиях — наоборот.
Многообразие — важный механизм эволиции. )
Конечно, я обычный человек, который может ошибаться, но над архитектурой редактора размышлял очень много времени. Это не единственный возможный вариант, но он мне очень даже нравится.
А потом сравните количество и читаемость получившегося кода. Получится лучше — поделитесь с сообществом своими наработками и видением. )
Что-то наподобие инициализационного блока с дополнительным префиксом и доступом к контексту через '.'
Для вас пишу, ведь это вы так волнуетесь о производительности. Мне достаточно и того факта, что методы-расширения по порядку величин сопоставимы с нативной реализацией. А в 4 или в 1.2 раза отличие для меня не критично, это не в 100 раз и даже не в 10.
Если честно, я не сравнивал производительность именно этого метода с нативной реализацией (да и нативная реализация не поддерживает fallbackValue), но не думаю, что различия будут более чем в десятки раз. Если вы исследуете декомпиляции нативного PM, то увидите, что в разных сценариях он раскладывается в конструкции анологичные перегрузкам метода Is.
Уже можно делать много интересных вещей, просмотрите примеры кода, связанные с Matching.
Почему раньше не сделали? Конечно, там умные люди работают, но вся система в целом иногда выдаёт странные и спорные решения. Поэтому не стоит слепо доверять даже авторитетам, а лучше всё переосмысливать самому.
Конечно, было бы здорово получить синтаксический сахар на нативном уровне вроде
но это вопросы к разработчикая языка. Я вносил подобные предложения, но дизайнеры уже приняли ряд весьма неоднозначных реший, первое из которых уже в релизе
Далее предполагаются
не знаю, как для вас, но для меня более очевидны такие формы
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте цистерну!
-Без проблем! Начинайте капать..."
Да и если здраво подойти к вопросу, то
"-Сколько у Вас стоит капля водки?
-Нисколько.
-Отлично! Накапайте стакан!
-Стакан стоит столько-то центов..."
:)
Знаете, ваша позиция напоминает мне такую: «Эти интегралы слишком сложные, нужно приложить усилия, чтобы научиться их читать и понимать, лучше я буду пользоваться школьной математикой». )
В первую очередь я отталкиваюсь от логики самой программы, сейчас она функционирует отлично.
Главной вью-модели вообще ни к чему знать об исключениях, возникающих в работе докуметов, там произойти может, что угодно: нет доступа к файлу, формат не тот… Пускай документы сами разбираются, что с этим делать. Задача руководителя лишь создавать их и закрывать, когда нужно, попутно уведомляя о загрузке, закрытии и сохранении.
Я, например, точно знаю, что в моих текущих проектах такого не придвидится, поэтому для себя никаких причин отказываться от паттерна не вижу.
По крайней мере, можно его использовать в задачах, где свехвысокая производительность не критична.