Это грамотная композиция, а не смешение. Мы берём фичи A и B, комбинируем и получаем C=AB, а не С=XB, где X это как A, но уже не совсем в данном контексте.
Матчить сложные паттерны можно уже сейчас (примеры см. тут).
Самое сомнительное решение дизайнеров языка — это неочевидное смешение матчинга по типу и по значению (например, в F# они разделены). Разбор имплементации здесь.
Вряд ли вы встречали прежде реализации многих рассмотренных решений. Можете, конечно, считать их полной чепухой, но они вполне рабочие и применимые на практике, не взирая на критерий «кроме вас».
Вероятно, если несколько людей читают в ваших комментариях одно и то же, стоит задуматься о том, что вы в них пишете?
Для себя я сделал такой вывод, да, есть люди, которые внимательно и вдумчиво читают комментарии, но есть и немало тех, кто слепо ориентируется на решения авторитетов и мнение большинства, не особо углублясь в детали, но тем самым поддерживая это большинство.
Отдельный вопрос — люди-авторитеты (например, из LDM). Мне было очень интересно, способны ли они открыто признавать своё неудачное решение или наоборот привести убедительные аргументы в его пользу. К сожалению, веского объяснения, почему сделано именно так, никто не привёл.
Интересно, что по последней информации LDM недавно реализовало в прототипе вместо p is { Name is «Abc» } другую форму p: { Name: «Abc» } для сохранения смысла операторов is (==, =), так что мои препирательства, возможно, оказали какое-то влияние.
Вот только убедительными аргументами вы считаете исключительно то, что вам удобно.
Как вам объяснить… Есть симметрия и математическая красота — это основные ориентиры для меня. Если вижу их очевидое нарушение, то прямо об этом говорю, здесь нет речи об удобстве или неудобстве аргументов для меня. В конце концов нашлись действительно строгие альтернативные решения, так что со спокойной душой я могу писать чистый код по своему разумению.
Там не было аргументированной критики. Вы просто повторяли одну шарманку «так писать плохо» и полностью игнорировали то, что вам пишут ответ.
Вероятно, вы не совсем внимательно читали мои комментарии и вникали в суть сказанного.
на личные скрытые почты LDM
Немногочисленные письма были отправлены лишь на личные открытые почты.
Вы не дискутируете. Вы выставляете ультиматум «СДЕЛАЙТЕ ВОТ ТАК», и не приемлете никакого иного решения...
С чего вы вообще взяли, что я ставлю ультиматумы и говорю, кому что делать? Меня по большей части интересуют поиски математической красоты в программировании, а не доказывание своей правоты. При наличии убедительных аргументов я легко признаю свои ошибки, что не раз случалось в дискуссиях, но пока таких аргументов нет — отстаиваю свою точку зрения, и только.
Мне неинтересно заниматься цеплянием к словам, поэтому я предпочитаю пользоваться вероятностными определениями и описанием мира.
Паттернном можно назвать как и сам белый шум, так и определённый закономерный сигнал, выделяемый из зашумленного канала в зависимоти от контекста использования и задачи.
Что касается паттернов в программировании, то их можно разделить по уровням абстракции. Сначала идут базовые паттерны самих языков программирования — это основные языковые конструкции, например, типы, циклы, условные выражения… Ведь что-то же отличает язык прораммирования от естественного человечкого языка, не так ли? Далее чуть более общее паттерны ToString, GetType, TryParse… Потом ещё более абстактные билдер, синглтон, фабрика… И в завершение, архитектурные — MVC, MVP, MVVM…
Вы, конечно, можете спорить со мной, переубеждать, но мне прекрасно живётся и с таким опредлением. Если оно вам не нравится, то продолжайте пользоваться своим, я даже не говорю, что оно в чём-то неправильное. Просто оно ваше — и это нормально разным людям иметь отличающиеся взгляды на какую-то тему.
Паттерн (информатика) — эффективный способ решения характерных задач проектирования, в частности проектирования компьютерных программ.
Эффективный способ решения характерной задачи с парсингом сторок в C# — это, например, использование конструкции int.TryParse(str, out var i). Но вы, конечно, можете реализовать и свой паттерн. :)
Ну, вы так и не предоставили убедительных для меня аргументов, обнаруживающих существенные недостатки, из-за которых мне стоило бы отказаться от своих кастомных решений.
Но отчего же вы до сих пор отвечаете на мой «спам» и выражаете своё мнение на его счёт? Может быть, это изощерённый спам особого рода, который заслуживает некоторого внимания?.. А я коварный и тёмный программист, который сеет очень плохие идеи в неокрепших умах юных разработчиков и соблазняяет более опытных переметнуться на его тёмную сторону? )))
Всё проще. Нет у меня подобных манихейских замашек, я всего лишь делюсь личным опытом.
Есть текстура, и если человек видит на ней узор (более-менее регулярную закономерность), то он вполне может сказать: «Я вижу геометрический паттерн такой-то», — и его поймут.
Паттерн предполагает закономерность. Закономерности можно искать и находить практически везде, и это очень близко к понятию пониженной энтропии. Вопрос лишь в том, насколько очевидна данная закономерность и насколько легко её выявить и проследить среди остального шума.
Так вот, код, где явно прослеживаются закономерности, с высокой степенью вероятности написан в согласии с определёнными паттернами, если же закономерности выявить затруднительно, то, возможно, его писали вразнобой.
Встречный вопрос, не надоело?
Как по вашему должен работать такой псевдокод
где базовый Shape (выведенный тип для var) поддерживает деконструкцию?
Если я пишу
и далее естественным образом заменяю на
с полным сохранением логики работы, то закономерно ожидаю аналогично симетрии для случаев
Увы, эта симетрия нарушена… Почему? Может, вы мне поясните примерами кода, где это крайне необходимо?
Самое сомнительное решение дизайнеров языка — это неочевидное смешение матчинга по типу и по значению (например, в F# они разделены). Разбор имплементации здесь.
(с заменой is var, case var на кастомные расширения)
Неплохой у меня код, уж я-то знаю. ;)
Вряд ли вы встречали прежде реализации многих рассмотренных решений. Можете, конечно, считать их полной чепухой, но они вполне рабочие и применимые на практике, не взирая на критерий «кроме вас».
Текущая реализация.
Отдельный вопрос — люди-авторитеты (например, из LDM). Мне было очень интересно, способны ли они открыто признавать своё неудачное решение или наоборот привести убедительные аргументы в его пользу. К сожалению, веского объяснения, почему сделано именно так, никто не привёл.
Интересно, что по последней информации LDM недавно реализовало в прототипе вместо p is { Name is «Abc» } другую форму p: { Name: «Abc» } для сохранения смысла операторов is (==, =), так что мои препирательства, возможно, оказали какое-то влияние.
Как вам объяснить… Есть симметрия и математическая красота — это основные ориентиры для меня. Если вижу их очевидое нарушение, то прямо об этом говорю, здесь нет речи об удобстве или неудобстве аргументов для меня. В конце концов нашлись действительно строгие альтернативные решения, так что со спокойной душой я могу писать чистый код по своему разумению.
Пускай и приблизительно, но, думаю, вы поняли мою позицию, а я вашу — они у нас разные, и это хорошо.
Немногочисленные письма были отправлены лишь на личные открытые почты.
С чего вы вообще взяли, что я ставлю ультиматумы и говорю, кому что делать? Меня по большей части интересуют поиски математической красоты в программировании, а не доказывание своей правоты. При наличии убедительных аргументов я легко признаю свои ошибки, что не раз случалось в дискуссиях, но пока таких аргументов нет — отстаиваю свою точку зрения, и только.
Человек, ознакомившись с материалами, сам поймёт, нужно ему это или не нужно. :)
Да? Но заинтересованные люди нашлись.
Паттернном можно назвать как и сам белый шум, так и определённый закономерный сигнал, выделяемый из зашумленного канала в зависимоти от контекста использования и задачи.
Что касается паттернов в программировании, то их можно разделить по уровням абстракции. Сначала идут базовые паттерны самих языков программирования — это основные языковые конструкции, например, типы, циклы, условные выражения… Ведь что-то же отличает язык прораммирования от естественного человечкого языка, не так ли? Далее чуть более общее паттерны ToString, GetType, TryParse… Потом ещё более абстактные билдер, синглтон, фабрика… И в завершение, архитектурные — MVC, MVP, MVVM…
Вы, конечно, можете спорить со мной, переубеждать, но мне прекрасно живётся и с таким опредлением. Если оно вам не нравится, то продолжайте пользоваться своим, я даже не говорю, что оно в чём-то неправильное. Просто оно ваше — и это нормально разным людям иметь отличающиеся взгляды на какую-то тему.
Всё проще. Нет у меня подобных манихейских замашек, я всего лишь делюсь личным опытом.
Есть текстура, и если человек видит на ней узор (более-менее регулярную закономерность), то он вполне может сказать: «Я вижу геометрический паттерн такой-то», — и его поймут.
Паттерн предполагает закономерность. Закономерности можно искать и находить практически везде, и это очень близко к понятию пониженной энтропии. Вопрос лишь в том, насколько очевидна данная закономерность и насколько легко её выявить и проследить среди остального шума.
Так вот, код, где явно прослеживаются закономерности, с высокой степенью вероятности написан в согласии с определёнными паттернами, если же закономерности выявить затруднительно, то, возможно, его писали вразнобой.