Ха-ха… «Заспамить»… Спам — это когда пишут рекламные сообщеия либо не связанные с основной темой обсуждения (оффтоп), но никак не аргументированная критика.
Действительно, понятие паттерна о-о-очень широкое…
И даже такие простые вещи, как способ чистки зубов, завязывания шнурков, манера говорить или выполнять либые другие регулярные действия, — зачастую обусловлены лишь поведенческими или моторными паттернами, привитыми, например, в раннем возрасте.
История такая: исходный аккаунт сначала забанили лишь в репозитории, но поскольку я всё равно продолжал отвечать на связанные вопросы людей, используя уже другие аккаунты (не скрывая своей личности), модератры нажаловались в поддержку гитхаба, дабы были приняты меры против неугомонного «спамера».
Но причины на самом деле во многом политические — просто критика в некотором роде подрывает авторитет разработчиков языка и «мешает» им работать. Если бы критические комментарии и аргументы были очевидно слабы, то почему бы их просто не проигнорировать? Зачем-то понадобилось блокировать человека… )
Называйте как хотите, но одно из общих значений понятия «паттерн» — это схема, закономерность чего-либо, например, действий при решении определённых задач.
Согласно такому определению ToString, TryParse, To, With… являются паттернами, поскольку подразумевают некоторые закономерности при написании кода.
У вас странное определение явности в программировании, оно сильно отличается от моего.
int i = 0;
long j = i; // неявно
long k = (long) i; // явно
var p = new Person();
p.Name = "abc"; // явно
var p = new Person
{
Name = "abc"; // неявное p.Name = "abc"
}
new Person().To(out var p).With
(
p.Name = "abc"; // явно
)
Именно, что «так», я описал конкретное условие (не единственное). Константы должны идти раньше покрывающего их типа...
В вашей изначальной формулировке вы упустили важное уточнение «покрывающего их типа», поскольку в общем случае типы и константы могут и не перекрывать друг друга.
А теперь давайте вспомним, что проверки на константы должны идти раньше проверок на типы, а null — это тоже константа. И где тут логика?
А что касается null, то никакой тип не может его перекрыть.
Как вы думаете, что будет, если написать так:
Мы надуем наш умный компилятор! :)
(очень поучительно посмотреть на релизный код при switch(6) и switch(5))
Ничего удивительного, компилятор удаляет недостижимые ветви кода.
Неа. В примере введено несколько временных однобуквеных переменных, которые надо отслеживать обратно к месту создания.
Для меня имя переменной не влияет на явность. Да, оно может влиять на читаемость кода, но не на явность. Если вы посмотрите декомпиляцию, то увидите, что инициализационные блоки тоже используют временные локальные переменные аналогичные To-With, разница лишь в том, что в первом случае эта переменная вводится компилятором неявно и к ней нельзя получить доступ из пользовательского кода, а во втором мы сами её явно объявляем и используем.
Затем же, зачем и With паттерн, потому что инициализационный блок — это всего лишь его частный случай с неявной переменной, чуть более лаконичным синтаксисом, но более ограниченными возможностями.
И даже такие простые вещи, как способ чистки зубов, завязывания шнурков, манера говорить или выполнять либые другие регулярные действия, — зачастую обусловлены лишь поведенческими или моторными паттернами, привитыми, например, в раннем возрасте.
Что уж говорить о программировании… :)
Но причины на самом деле во многом политические — просто критика в некотором роде подрывает авторитет разработчиков языка и «мешает» им работать. Если бы критические комментарии и аргументы были очевидно слабы, то почему бы их просто не проигнорировать? Зачем-то понадобилось блокировать человека… )
Согласно такому определению ToString, TryParse, To, With… являются паттернами, поскольку подразумевают некоторые закономерности при написании кода.
Стоит лишь различать архитектурные паттерны (MVC, MVVM, Singleton...) и микропаттерны (ToString, TryParse, To, With...).
Поскольку снова назревает спор по терминологии, предлагаю каждому остаться при своём мнении. =)
Верно. Но я говорю про перекрытие именно в контексте оператора switch.
Насчёт странных и непредсказуемых декомпиляций оператора switch ничего толкового не скажу, эти вопросы лучше направить разработчикам компилятора. :)
А что касается null, то никакой тип не может его перекрыть.
Мы надуем наш умный компилятор! :)
Ничего удивительного, компилятор удаляет недостижимые ветви кода.
Нет, вы путаете. Это рабочий код
И по моей логике он должен быть абсолютно эквивалентен
Увы, текущая реализация в C# этому не соответствует.
Во-вторых, не знаю, как для вас, но для меня цепочные вызовы выглядят намного более структурировано и читаемо.
А я не против. )
Вообще-то в примере они описаны явно и прекрасно работают.
Так никогда не пробовали написать?