Здравствуйте, Serginio1, Вы писали:

S>И ты тудаже.

Я оттуда же и не возвращался еще.

Весь код по ссылке именно таков как раз от того, что дотнетный якобы "параметрический полиморфизм" не в состоянии разресолвится статически, исключив динамику интерфейсных вызовов, потому что не реализует статически даже полиморфизм 1-го ранга, в отличие от того же Хаскеля, который ровно в этих же сценариях ресолвит всё статически.

S>По приведенной ссылке прежде много кода генерится всего из за того, что код не инлайнится.

А вот ты именно что "туда даже" в пытках облегчить себе задачу, прилюдно допустив, что оппонент нифига не понимает.
Тот код по ссылке в том числе избавляет и от copy&paste.


S>Я привел тебе ссылки где методы инлайнятся и нет разницы между value и ref типами

Мне приводили много разного кода. В них было разное:
— ad hoc полиморфизм на лямбде, хотя спор идёт о параметрическом полиморфизме (дополнительно я делаю замечание о том, что код лямбды — это copy&paste, ты же мужественно делаешь вид "ну и что?"... мужик, мужик... так закалялась сталь! ))
— параметрический полиморфизм, не способный разресолвится статически, т.е. работающий через метод интерфейса.

Ну и, я и сам смогу тебе привести сходу пример, где такой полиморфизм сможет разресолвится статически в дотнете, я уже озвучивал — это при использовании технологии "объекта-словаря операций" (и в приводимых к этой концепции сценариях), где сам такой объект представлен value-типом. Ну не популярная эта техника нифига в дотнете. Там никто не таскает в логике эти словари рядом с целевыми объектами, везде идёт попытка работать с объектами напрямую. А когда напрямую, то возвращаемся к самому первому моему утверждению:

Собсно, вообще таких алгоритмов мало, которые можно выразить в дотнете для value и ref-типов в генериках и они будут корректно работать в обоих случаях.

Потому что получается так, что лишь теми операциями, которыми обложили базу объекта (интефейс интерфейса или публичный интерфейс базового класса) и можно оперировать. И шаг вправо-влево сделать вааще никак.

Но спорить с подобными утверждениями тоже надо уметь. Пытаясь мне показать, что такие алгоритмы все-таки есть, вы показываете банальное невладение логикой. ))


S> А что же это такое? Лямбда, замыкание, который может захватывать и внутренние переменные например
S>var f=5;
S>.Where(x => x > q+f).Select(x => x + f).Sum();

Сорри, но рука, таки, добежала до лица.
Ты зачем ввёл f? У тебя там уже был q ровно в этой же роли.

Как сам считаешь, я ждал подобного примера, или нет?
Я ждал тыкания в меня переменной q. Кароч, ты даже превзошёл мои ожидания. ))

У меня уже был заготовлен тот ответ, что захват контекста "by name" и "by value" — это принципиально различные вещи. Когда мы захватываем контекст by value, т.е. специализируем аргумент(ы) некую ф-ию константой(ами)/значением(ями), то для таких вещей достаточно техники частичной специализации. Ну да, её нет в явном виде в C#, поэтому везде идёт лямбда. ))


S>Еще раз посмотри как эти лямбды разворачиваются

Зачем? Думаешь, с первого раза не дошло?
Или, думаешь, что можно запросто игнорить уже данный на это ответ:

Это всё к тому, что твой пример с copy&paste вот этого:
...
в общем случае является плохой практикой.
Но язык позволяет только такую.

V>>Т.е., речь о том, что неуникальный случай в C# описать не так-то просто (тем паче с должной эффективностью).

И вот тут ты не ответил. А ведь это был ответ на тот вопрос, который ты пытаешься повторять уже, еще не "отстрелявшись" с должной убедительностью по уже данным моим замечаниям.


V>>Не можешь. В теле дотнетной лямбды происходит автовывод типов, поэтому ты вызываешь методы конкретных типов. А для реализации предиката в виде генерика исходные типы должны поддерживать некие данные ЗАРАНЕЕ ограничения на шаблонах или использовать т.н. "объекты-словари операций", навроде IComparer<T>, который в свою очередь может оперировать лишь типами, над которыми ПРЕДВАРИТЕЛЬНО заданы некие ограничения в виде опять и снова интерфейсов.
S>И что мне мешает объявить метод?

Ничего. "Объекты-словари операций" — отличная техника.
(Ты хоть понимаешь, о какой технике речь? А то, может, я с тем же успехом мог с Космосом разговаривать всё это время)

Но что мешает использовать эту технику повсеместно в дотнете, Ы?
Может, то, что в концепции дотнетного ООП такая техника выглядит заимствованием из чужеродного ФП?
Т.е., те фишки ФП, которые не руинят ООП — они в практику дотнета таскаются с удовольствием, смотрю. Остальные практики игнорятся, хотя именно такая реализация параметрического полиморфизма требует именно таких практик. ))


V>>Конечно удобны. Но я на это тоже уже отвечал заранее:
V>>

V>>Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.

V>>С++ позволяет комбинировать технику шаблонов и лямбд, используя каждую из техник по прямому назначению, т.е. заставляя их выполнять исключительно "свою" часть работы.
S>Это же все можно делать и на C#

Можно, но сложнее, чем в С++ и это, блин, очевиднее ж некуда. Т.е. меня во всём этом споре удивляет такая высокая мотивированность оппонентов спорить с очевидным. Понятно же, что в тех случаях, где код в С++ можно продолжать оформлять в концепции ООП и всё еще получать инлайнинг и тру-статический ресолвинг параметрического полиморфизма, в дотнете уже требуется аналогичный код переводить в хардкорный ФП, резко повышая тот самый "порог вхождения" бедного дотнетного программиста. ))

Ну или подменять генерики на лямбды, т.е. параметрический на ad hoc полиморфизм, но это уже сразу вылет за границы обсуждаемого и желтая карточка оппоненту. Лично ты этих желтых карточек набрал уже — у-у-у-у )))