MD>Собственно, весь LINQ такой и есть, а также всякие автомэпперы-миграторы-etc
Да, но реализация возлагается на программиста, хотя это легко было добавить в ядро языка.
как только линк или экстенш для операции не реализован, так сразу либо временные переменные либо матрешка функций.
UFCS и для чтения прост и для уменьшения лишних LOC
Нет, не решает. А должно? Если вы зайдете в список предложенных фич для C#, то увидите, что их там тысячи. Понятно, что все они никогда не будут реализованны. Данная фича хороша, но для большинства не критична.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Собственно, весь LINQ такой и есть, а также всякие автомэпперы-миграторы-etc
vaa>Да, но реализация возлагается на программиста, хотя это легко было добавить в ядро языка. vaa>как только линк или экстенш для операции не реализован, так сразу либо временные переменные либо матрешка функций. vaa>UFCS и для чтения прост и для уменьшения лишних LOC
Не методы расширения интереснее, так как можешь добавлять методы не изменяя класс. Главное ты можешь использовать различные методы с одним названием используя пространства имен.
Часто приходится использовать условную компиляцию, так как в Xamarin есть методы объекта, а для фреймворка нужно делать методы расширения.
Ну и раз есть методы расширения конфликтующие с обычным методом то какой должен вызваться?
Но можно отрефакторить f1(f2(f3(f4(f5(1))))) в класс расширения и вызывай 1.f5.f4.f3.f2.f1
Просто это оооочень редкая задача
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Хэлкар, Вы писали:
Х>Нет, не решает. А должно? Если вы зайдете в список предложенных фич для C#, то увидите, что их там тысячи. Понятно, что все они никогда не будут реализованны. Данная фича хороша, но для большинства не критична.
Надо реализовать 1+2 фичи позволяющие людям создавать свои синтаксические расширения, а остальное возложить на пистелей библиотек.
MS тратит десятки лет, чтобы потом изобрести то, что существует уже почти 20 лет.
Здравствуйте, vaa, Вы писали: vaa>не то, глобально это не решает проблему f1(f2(f3(f4(f5(1))))) вместо 1.f5.f4.f3.f2.f1
А такая проблема есть?
В тех местах, где она может проявиться, используют именно extension methods.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vaa, Вы писали: vaa>>не то, глобально это не решает проблему f1(f2(f3(f4(f5(1))))) вместо 1.f5.f4.f3.f2.f1 S>А такая проблема есть?
Скобки это препятствие на пути к чистому коду. S>В тех местах, где она может проявиться, используют именно extension methods.
не универсально и увеличивает количества бойлерплэйта в проекте. По моему какой-то костыль.
Здравствуйте, vaa, Вы писали: vaa>не универсально и увеличивает количества бойлерплэйта в проекте. По моему какой-то костыль.
Не, ничего не увеличивается.
Было бы интересно посмотреть на реальный пример кода, который страдает от nesting problem, и который можно было бы как-то существенно улучшить вот этим вот костылём, но нельзя при помощи extension methods.
Пока что выглядит так, что у вас тяжёлое поражение ФП, при котором кажется, что большинство функций являются безаргументными.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Пока что выглядит так, что у вас тяжёлое поражение ФП, при котором кажется, что большинство функций являются безаргументными.
Здравствуйте, D. Mon, Вы писали:
DM>Зачем безаргументными? В общем случае там DM>
DM>a.f1(b,c).f2(d).f3(x,y,z)
DM>
DM>преобразуется в DM>
DM>f3(f2(f1(a,b,c), d), x,y,z)
DM>
DM>Порой весьма удобно.
Это как раз совпадает с синтаксисом extension methods.
ТС хочет избавиться от скобок, вместо a.f1().f2().f3() писать a.f1.f2.f3. Как в Паскале.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
