Ко мнениям окружающих я прислушиваюсь и при достаточной аргументации готов даже поменять своё личное.
К сожалению, убедительных аргументов в пользу того, что 'is var' и 'case var' для чего-то должны возвращать всегда только 'true' мне найти не удалось, хотя обратных доводов могу привести немало.
Вовсе не утверждаю, что теперь нужно вносить breaking changes, меня больше интересует, как мог бы выглядеть язык в идеальном случае. Ну, и то, что можно теперь использовать методы расширения 'Is' с чистой и предсказуемой имплементацией в случае необходимости. Кстати, для подхода с методом 'Is' можно также получить ряд любопытных обобщений, которых нет сейчас в языке.
— нельзя без замыканий выводить значения в новые переменные (производить деконструкцию объекта)
var manager = GetPerson().To(out var p).With(
p.FirstName.To(out var oldFirstName),
p.FirstName = "Иван",
p.LastName = "Пупкин",
p.ToString().To(out var personStringView),
});
— нет возможности удобно модифицировать структуры
struct Person { ... }
var manager = GetPerson().With(o => {
o.FirstName = "Иван";
o.LastName = "Пупкин";
});
Console.WriteLine(manager.FirstName); // получим исходное значение вместо "Иван"
— больше скобок и меньше похоже на инициализационные блоки
Хотя, конечно, никто не отменяет и этот подход, кому что ближе. :)
Ссылка для информации и просто для тех людей, кому интересна тема.
Выгляди так, словно ваша самоцель — обсуждения на хабре. Моя цель — поиск истины, математической красоты и рабочих решений, а обсуждения — только малая часть этого пути.
По правде говоря, я уже устал обсуждать эту тему, поскольку обсуждалась она не только тут. В английском варианте собраны финальные аргументы, и люди, которые приложили некоторые усилия, смогли уловить их смысл.
Это вы так считаете, но касательно меня это мало о чём говорит. Да и репозитории тоже публичные, так что я показываю значительно больше, чем вы видете здесь, и лишь ваша принципиальная позиция ограничивает вам самим обзор. )
Хорошо понимаю, что на первый взгляд все эти конструкции выглядят жутко непривычно, но когда к ним привыкаешь, то постепенно начинаешь видеть их красоту. К тому же никто не призывает использовать сложные рекурсивные выражения, можно ограничиться простыми и понятными, например,
Граница есть, но лишь условная, поэтому вы можете её свободно пересекать в любую сторону — в этом своя прелесть!
Этот подход плохо применим в командной работе.
Отчасти поэтому мне больше нравится писать код самостоятельно. Но как бы там ни было, я совсем не принуждаю кого-то следовать рассмотренным концепциям, всего лишь делюсь личным опытом и наработками.
Если вам любпытно, то вы и сами можете немного полазить по репозиториям и субъективно оценить качество кода, написанного мной. ))
Вообще-то в нашем случае 'with' выражает пусть и видимую, но вполне осязаемую структуру кода.
Приведу такую аналогию, у вас есть детская машинка, вы можете разобрать её на части и потом собрать. Поскольку все детали плотно подогнаны друг к другу, то вряд ли выйдет собрать что-то иное.
Теперь у нас есть конструктор или лего, из которых можно собрать множество вариаций автомобилей и не только, даже самых нелепых и абсурдных! Огромный простор для фантазии!
В программировании для меня намного более близок второй подход. Пускай лучше инструменты позволяют делать даже бредовые вещи, как их примениять или не применять, это уже мне самому потом решать. :)
Да, контекст не влияет на поведение 'with' и аргументы. Здесь ответственность программиста и полная свобода действий.
Лично для меня близка свобода в программировании, делай, как тебе нравится, а если что-то работает не так, то сам виноват. Меньше ограничений — больше возможностей.
Монады не позволяют совершать деконструкцию объекта и объявлять новые переменные для дальнейшего использования в вызывающем методе.
Для меня видимость структуризации, читаемость и выразительность — очень близкие в данном случае понятия.
Но особенно меня цепляет глобальная симметричность и математическая красота подхода в плане обобщений. Это трудно объяснить и сразу прочувствовать, но мне самому теперь нравится, хотя поначалу были сомнения в его целесообразности.
К сожалению, убедительных аргументов в пользу того, что 'is var' и 'case var' для чего-то должны возвращать всегда только 'true' мне найти не удалось, хотя обратных доводов могу привести немало.
Вовсе не утверждаю, что теперь нужно вносить breaking changes, меня больше интересует, как мог бы выглядеть язык в идеальном случае. Ну, и то, что можно теперь использовать методы расширения 'Is' с чистой и предсказуемой имплементацией в случае необходимости. Кстати, для подхода с методом 'Is' можно также получить ряд любопытных обобщений, которых нет сейчас в языке.
— нельзя без замыканий выводить значения в новые переменные (производить деконструкцию объекта)
— нет возможности удобно модифицировать структуры
— больше скобок и меньше похоже на инициализационные блоки
Хотя, конечно, никто не отменяет и этот подход, кому что ближе. :)
Выгляди так, словно ваша самоцель — обсуждения на хабре. Моя цель — поиск истины, математической красоты и рабочих решений, а обсуждения — только малая часть этого пути.
Если же вы не улавливаете взаимосвязи, то, к сожалению, ничем не могу помочь.
bitbucket.org/Makeloft/ace/issues/1/research-of-pattern-matching
CC: lair PsyHaSTe orthoxerox
Отчасти поэтому мне больше нравится писать код самостоятельно. Но как бы там ни было, я совсем не принуждаю кого-то следовать рассмотренным концепциям, всего лишь делюсь личным опытом и наработками.
Если вам любпытно, то вы и сами можете немного полазить по репозиториям и субъективно оценить качество кода, написанного мной. ))
Приведу такую аналогию, у вас есть детская машинка, вы можете разобрать её на части и потом собрать. Поскольку все детали плотно подогнаны друг к другу, то вряд ли выйдет собрать что-то иное.
Теперь у нас есть конструктор или лего, из которых можно собрать множество вариаций автомобилей и не только, даже самых нелепых и абсурдных! Огромный простор для фантазии!
В программировании для меня намного более близок второй подход. Пускай лучше инструменты позволяют делать даже бредовые вещи, как их примениять или не применять, это уже мне самому потом решать. :)
Лично для меня близка свобода в программировании, делай, как тебе нравится, а если что-то работает не так, то сам виноват. Меньше ограничений — больше возможностей.
Монады не позволяют совершать деконструкцию объекта и объявлять новые переменные для дальнейшего использования в вызывающем методе.
Для меня видимость структуризации, читаемость и выразительность — очень близкие в данном случае понятия.
Но особенно меня цепляет глобальная симметричность и математическая красота подхода в плане обобщений. Это трудно объяснить и сразу прочувствовать, но мне самому теперь нравится, хотя поначалу были сомнения в его целесообразности.
Да, одинаковые названия переменных будут конфликтовать, но есть возможность их повторного переиспользования.