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

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

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

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

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

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

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

Я к тому же, что этот пример приводит постоянно один человек, и считает это доказательством дефекта .Net. Это как про Каррузо, которого Моня напел.

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

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

Какя лямбда копи пасте? Для Where и Select по сути нет одинаковых методов, но если они нужны я могу where заменить на специализированную функцию. Нет проблем.
Linq to EF. Практика использования. Часть III


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

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

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

Угу все коллекции, словари прекрасно работатют и с теми и другими типами.

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


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

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

Затем, что бы дать понять, что это замыкание.

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

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

Еще раз по своей сути лямбда мало отличается от C++ лямбды. Её так же можно развернуть в инлайн код.
Просто это только сейчас начинается.


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

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

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

Ты хоть объясни про copy&paste. Нет у меня одинаковых Where а там где есть, я могу либо заменить Where на свою спец функцию, либо добавить любой метод Func(T,bool)

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

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


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

Так ограничения это хорошо. Мы сразу видим какие методы поддерживаются при создании дженерик класса. Но при этом мы можем и проинлайнить этот метод при специализации.
S>>И что мне мешает объявить метод?


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

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

Делают делают. Но неспешно.

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

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

На самом то деле как правило ограничения не большие. Ну и никто не мешает тебе вывести в отдельную функцию. В чем проблема я не вижу.


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

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

Наоборот легче. Так ка я на стадии кодирования дженерик метода получаю и интелиссенсе и проверку. А вот компиляторо на этапе в компиляции в IL может так же инлайнить при специализации .


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

Ну да лучше писать и надеяться что есть перегрузка оператора без интелиссенсе и искать ошибки при специализации шаблона.
ууууу