Предчувствуя, что явный офтопик в теме про навязший всем в зубах полиморфизм так или иначе забанят, рискну продолжить обсуждение в новой ветке.

Краткое intro: судя по тенденциям в т.н. "мейнстриме" современных ЯВУ (еще тынц и тынц ), в последнее время прослеживается явный тренд от чисто "императивных" языковых конструкций к более-менее "декларативным"... (чисто "декларативными", к сожалению, пока невозможно решить все существующие задачи).

Все кругом (и NGGU в цитируемом топике про полиморфизм, и В. Шепелев в своих обзорных статьях, и мн. др. в разных других местах) отмечают "крутость", "полезность", "перспективность" и т.д. - возникновения такого явления, как, например, LINQ/C#3.0 (то, что эти 2 понятия - суть "близнецы-братья" будет объяснено позже).

Что же мы имели в начале?
Когда-то давно умные дядьки из Редмонда решили "прикрутить" к платформе .NET (или даже к конкретному ADO.NET) "всего-то-навсего" кусочек "синтаксического сахара" для удобной манипуляции данными (на уровне реляционной модели) на стороне клиента... (тем более, что удобный "прототип" для реализации уже был "практически" готов в виде System.Data.DataSet, который позиционировался, ни много, ни мало, как - "целая БД" внутри памяти клиентского приложения).
То ли "сообщество FoxPro" заклевало "сообщество .NET" своими "клиентскими курсорами" и "встроенным SQL", то ли еще какая иная благая мысль закралась в их умные головы (действительно: хрен ли - "БД в памяти" есть, а "диалекта SQL" для нее - нету, "неаккуратненько как-то"), но результат оказался - необычен во всех отношениях.

Для того, чтобы реализовать задуманное не "грубой силой" (ака "вкручивание" на выбор: пре-процессорных директив, атрибутного ORM, или еще каких-нить иных "рефлексионных чудес"), а вполне себе "концептуально", в рамках т.с. "основной парадигмы" - был выбран путь тоже казавшийся вначале "проторенным", т.к. System.CodeDom и System.Reflection.Emit тоже, вроде бы, к тому времени уже существовали и были "практически" готовы к решению поставленных задач.

Однако ж, когда дошло до "дела", то выяснилось, что оказывается - мало "разложить" выражение типа "select a from b group by c order by d" в дерево вызовов AST типа b.Group(c).Order(d).Select(a);
Оказывается, что надо еще как-то реализовать "where" и желательно на уровне AST получать не ...Filter( _variable )...; (потому что _variable еще как-то "инстанцировать" по контексту придется), а сразу иметь возможность передать туда "компаратор" с заранее выставленными условиями сравнения (но компараторы - громоздки в записи, а без анонимных делегатов так и вообще - отделены от AST LINQ-выражения их использующего), или что-то еще, само-по-себе "знающее" и "умеющее" как и что сравнивать/фильтровать... (а что может быть проще и понятнее "лямбды" в таких условиях?).

Ну что ж, подумали дядьки, "лямбды" так "лямбды", всего делов-то... Вон, в том же Nemerle - вообще одни сплошные "лямбды" и ничего, живут себе люди и "в ус не дуют", в IL компилируются, под CLR выполняются, нешто и мы не смогем?

Ну а дальше, как говорится: "коготок увяз - всей птичке пропАсть...", чтобы "лямбды" можно было инстанцировать "по месту" на сцену выходят: "выведение типов", "анонимные конструкторы" даже "анонимными типами" не побрезговали... (вали все до кучи, чего уж там).

Что же мы имеем в итоге?
C#3.0 - практически превращается в ФЯ, сан-техники смотрят на ето дело и срочно пытаются повторить то же самое с Java, Nemerle - гордо ждет когда его "примут" в мейнстрим, Haskell и Erlang "нервно курят в сторонке" и недоумевают - "а мы что, уже больше не такие особенные?"...

Так ли это на самом деле, или я просто - слишком много нафантазировал, обладая только обрывками информации?

mayton...Давайте откроем спецификацию C#3.0 (кстати где она?) и внимательно почитаем...

А я чем, по вашему, занимался перед тем как запостить этот спич?
Именно - внимательно "читал спецификацию" (кстати, вот она , не БГ весть что - просто вордовый файлик с описанием наиболее "продвинутых" фич, но зато - прямо из "первоистчника").
Причем, именно "внимательное" чтение упомянутого выше документа и привело меня к построению "цепочки зависимостей": LINQ -> AST -> "lambdas" -> (all other FP stuff) -> C#3.0.
Так что, не такая уж это и "фантазия"...

maXmoбольше кода
Это вы - "обо што"?
Если нужны примеры новых фич C#3.0 - см. по ссылке выше...

maXmoбрр… там написано, что лямбды – это чисто синтаксический сахар над генериковскими делегатами...
Если так рассуждать, то весь Nemerle - "это чисто синтаксический сахар над" CLR/IL.
Однако ж, жив "курилка", и вполне себе за ФЯ сходит...

dejavew maXmoбрр… там написано, что лямбды – это чисто синтаксический сахар над генериковскими делегатами...
Если так рассуждать, то весь Nemerle - "это чисто синтаксический сахар над" CLR/IL.
Однако ж, жив "курилка", и вполне себе за ФЯ сходит...

Что-то перечитал еще раз про "Lambda expressions", ей-БГ, не заметил ничего "порочащего" их "функциональную чистоту", кроме того, что они могут неявно каститься в генерик-делегаты там, где это необходимо "по месту".
По-моему, все-таки это не "синтаксический сахар над генериковскими делегатами", это что-то "бОльшее"...
(вот цитатка: "... Lambda expressions are a functional superset of anonymous methods, providing the ... additional functionality...")

Partisan MНет перспектив конвергенции - ни полной, ни частичной. Мысли о конвергенции могут возникнуть у любителя ф.п. которого печалит - а почему публика равнодушна к языкам вроде Haskell и Erlang? ...
Ну, не знаю...
Я себя к "любителям ф.п." отнести не могу, т.к. узнал о нем совсем недавно, со страниц того же RSDN (кстати, а чем он так вам не угодил, что сразу - "превратился в помойку"?).
Зато я вижу отчетливо, что происходит в синтаксисе т.н. "обычных" ООЯ по мере движения их по шкале времени вперед...
Те же самые приснопамятные "лямбды" (ака "анонимные делегаты", ака "упрощенная запись функторов с одним методом") даже если признать их "синтаксическим сахаром" над встроенными в платформу (любую) ОО-типами - ясно показывают, что такая "запись" проще, понятнее и удобнее в использовании для практических задач, и поэтому "кит" и "слон" - повсеместно тащат за уши этот "сахар" в свои ООЯ, придавая им "неявные" черты ФЯ - т.е. думающие люди выбирают путь развития для своих ООЯ не по принципу "академичности" и "концептуальности", а по принципу - "практичности" и "удобства"...

З.Ы. а что за слово такое - "пуюлике"? и в каком контексте вы его использовали?

мод...
А можно нескромный вопрос: что такое функция с точки зрения ООП: метод, свойство или что-то еще ?
А вам-то, как поклоннику "утиной типизации" какая разница?
Если оно "крякает" как функция, "ходит" как функция, "плавает" как функция - используйте "это" по месту употребления функции... (например, как "уточняющий" аргумент в вызовах ФВП вроде map, fold или foreach).
Или вы хотите, чтобы "внутри" среды исполнения была соблюдена "концептуальная чистота", т.е. lambda expressions "разворачивались" компиллятором не в "делегаты", или в "функторы", а во что-то еще более "концептуально чистое", вроде "функциональных объектов первого рода"?
По большому счету, на данном этапе развития технологии (ИМХО) - "с головой" хватит и "делегатов" (с "функторами"), а ввести при необходимости (в борьбе за ту же "мифическую" производительность) в FCL дополнительную сущность - труда не составит (или немного "обработать напильником" концепцию делегатов).

З.Ы. если отвечать прямо на поставленный вопрос, то для меня "функция в ООП" - это отдельный класс сущностей, характеризуемых только выполняемыми ими действиями, в самом грубом приближении - "публичный класс с единственным исполняемым методом по-умолчанию". Но, как правильно заметил NGGU (да и не он один) - в синтаксисе "классического" ООП такие конструкции довольно громоздки и запутывают суть происходящего в коде за паутиной "служебных" объявлений... А при введении в синтаксис ООЯ lambda expressions (ИМХО) - вся эта "паутина" отметается на совесть компиллятора... Вот и вся недолга...

мод... зы а утиная типизация это что ?
Прикалываетесь, или правда - ни разу не слышали такого "термина"?
(да, в том же приснопамятном RSDN #4, 2006 - это словосочетание упоминается по 10 раз чуть ли не в каждой статье, а там всего 3 "программных" статьи: Haskell, Ruby, Nemerle).

Ну, если и правда не доводилось слышать - это такое правило "мягкого" выведения типов принимаемых аргументов, когда на тип аргумента не ставится никаких дополнительных "ограничений", сверх того, что необходимо "принимающей стороне" для их успешной обработки (больше характерно для т.н. "динамических" ЯВУ, чем для ФЯ/ООЯ).
В ООП-аналогии похоже на повсеместное использование "интерфейсов" вместо иерархии наследования конкретных и абстрактных базовых классов (типов).
Т.е. условно говоря, "договариваемся" о том, что MyCoolDataGrid, к примеру, будет способен отображать на GUI любые коллекции, реализующие IEnumerable с элементами, умеющими реализовать ToString() - и все... больше MyCoolDataGrid-у "заботиться" не о чем... хоть DataSet ему передавай, хоть List<int>, хоть MyCoolObject[] - он их всех "аккуратно" отобразит в клеточках по-порядку... потому как - "крякает" то, что ему передается - "как утка" (т.е. умеет "последовательно перебираться методом MoveNext()") и "плавает как утка" (т.е. умеет "отобразить себя методом ToString()"), значит для MyCoolDataGrid-а это и есть - "утка" (он только с такими "утками" и умеет работать, и что там конкретно за тип ему передается для отображения: DataSet, коллекция или массив - ему абсолютно фиолетово).

мод dejavewи что там конкретно за тип ему передается для отображения: DataSet, коллекция или массив - ему абсолютно фиолетово).
Спасибо, не знал. Но я действительно сторонник мягкой типизации или даже ее отсутствия...
Велкам, как говорится... (значит, насчет вашей приверженности мягкой типизации я угадал).

мод... Возвращаясь к функциям в ООЯ: нужно ли объявлять класс для одной единственной функции ? Или можно просто объявить функцию вне всякого класса.
Если вы спрашиваете мое личное мнение - то мне пока все равно... (исходя из той же концепции "мягкой типизации" или избегания всяких "жесткостей" без явной на то необходимости).
Ведь, что по-сути происходит в коде ОО-программы на C# когда кто-то пишет в теле класса что-то типа такого (expression):
Это похоже на "объявление поля события" с "именем" Alarm и "типом" AlarmEventHandler внутри класса, хотя, на самом деле CLR (компилятор) - создает поле делегата типа System.MulticastDelegate c "внутренним" признаком того, что он может выполнять методы (функции) с сингатурой, описанной уже вне класса другим "выражением" (expression):
И одно выражение и другое - "синтаксически" выглядят как "объявления" чего-то связанного с вызовами событий/обработчиков, но на самом деле - таковыми не являются, т.к. первое создает поле System.MulticastDelegate внутри класса, а второе - уточняет сигнатуру конкретного System.MulticastDelegate (или его неявного прямого наследника, но нам-то - какая разница?), который будет использоваться "по месту" везде, где встретится вызов "типа" AlarmEventHandler...
К чему мы приходим относительно вашего вопроса?
В контексте использования lambda expressions - какая разница во что "выводятся" компиллятором синтаксические конструкции вроде этих?
Если это будет "служебный" приватный метод класса (выведенный "умным" компиллятором из "знания" о том, что все аргументы и результат не выходят за scope одного и того же "внешнего" вызова) - замечательно... (ничего проще и яснее - придумывать не надо).
Если это будет "служебный функциональный объект" с одним и тем же методом (условно говоря - ___execute_me___()) в который из "лямбды" попадет только "тело" - ничего страшного в этом тоже нет.
Даже если это будет - "полновесный" генерик-делегат со всей его "обвязкой" в виде XXXEventArgs, add, remove и перегрузкой операторов "+=" и "-=" - тоже вполне приемлемое "решение", по крайней мере - пока...
Ну и сами скажите теперь - зачем при таком "выведении" сущностей исполняющей среды (types) из выражений ООЯ (expressions) нужно где-либо что-либо еще объявлять ("функции вне классов" или "классы для функций")?
"Все уже объявлено до нас..." - перефразируя известный фильм...

мод
Я бы со многими вашими тезисами поспорил...
Поэтому, придется - по порядку следования (хоть, и ненавижу я interlaced quoting, вобщем-то).
мод...Ну саму-то функцию надо где-то объявить.
Первое "спорное" утверждение - "функция" как сущность ЯВУ определенная в синтаксисе этого ЯВУ (т.н. "ex-функция", от "expression") вполне может обойтись и без явного "объявления".
На примере тех же "лямбд", "выведения типов" и пр. "pattern matching"-ов, мы уже сейчас можем убедиться в том, что для адекватного описания смысла происходящих действий на любом ЯВУ-диалекте практически необязательно "объявлять" в явном виде: имя "функции", "типы" ее аргументов, области "видимости" и пр. "классическую" лабуду, служащую лишь "синтаксической обвязкой" над единственным и неповторимым "смыслом" этой сущности - ее "телом" (где явно должны быть описаны действия или результаты, которые мы ожидаем от ее выполнения).
С другой стороны - "функция" как набор инструкций Х86 или "виртуальной машины" среды исполнения (CLR/JVM) это уже совсем другая сущность (т.н. "rt-функция", от "run-time"), и ей безусловно необходимы все вышеперечисленные атрибуты (имя/адрес, сигнатура, scope) или их "отображения" на семантику этой самой среды исполнения.
Но, беда (или радость?) в том, что сред исполнения ЯВУ может быть бесконечно много и даже при сходной внутренней архитектуре (например - "все - объект") они могут сильно различаться вариантами реализации и "стилевыми особенностями" этого самого "отбражения" (условно говоря: кому проще сделать из "ex-функции" класс - тот делает класс, которого мы никогда не "увидим", пока не залезем в исполняемый код "грязными руками", aka reflector, aka binary debugger, etc). Кому проще сделать из "ex-функции" скрытый метод текущего класса - делает скрытый метод. И т.д. - "по индукции"...
мод... Заводить для этого класс явно лишнее.
Что есть "явно лишний" класс в вашем понимании,
Если этот класс является: чисто служебным, генерируемым автоматически при компиляции "ex-функций" в "rt-функции", скрытым от пользователя (в данном случае программиста), и занимает в памяти не более пары десятков "лишних" байтов, не считая собственно реализации "тела".
мод... Получается "функция вне классов", но это фактически означает включение в ООЯ элементов "не ООП", т.е порождаем некий гибрид, что не есть хорошо.

По-моему, вы сами себе "страшилки" выдумываете - lambda expression не может быть "вне классов", т.к. фактически в ООЯ используется либо для передачи в качестве аргумента в ФВП (локальное значение), либо для определения и последующего манипулирования "повторно-используемого" блока кода (приватный или публичный мембер). Зачем "ex-функциям" быть "вне классов" я пока не совсем понимаю... (для них и "внутри классов" дел хватает).
мод
зы lambda expression как любое выражение всегда локально (пмсм), а вот имя функции имеет область видимости.

Как мы уже договорились раньше - имя для "ex-функции" не существенно, т.к. "настоящее имя" ей все равно присвоят компилятор/среда исполнения. Поэтому рассуждать об "области видимости" того, чего нет - бессмысленно.
А по поводу заведомой "локальности" "ex-функции" - тоже не все так однозначно, она безусловно "локальна" по месту определения (внутри метода класса), но при этом - никто не запрещает из того же самого метода перекинуть ссылку на "ex-функцию" в другой метод, или даже в другой объект/класс, вот тут "локальности" и приходит "кирдык". А если вспомнить еще и про необходимость "замыкания контекста" в теле "ex-функции" (а в контексте легко могут "завязнуть" внешние ссылки), то от "локальности" остается совсем немного... (так что, вполне возможно, что мое предположение о том, что "ex-функцию" можно будет "развернуть" в приватный метод того же самого класса - очень оптимистично и обложено массой "дополнительных условий", за которые разработчики CLR даже бороться не станут).
мод
ззы и еще - если что-то выглядит как кошка, то это и должна быть кошка, т.е. синтаксис и семантика элементов языка должны соответствовать друг другу.
Ну-у-у-у, тут уж даже не знаю - что и возразить, почему вам, вдруг, показалось, что введение в ООЯ "ex-функций" нарушает ОО-семантику? Только лишь потому, что рядом с lambda expression нигде в синтаксисе не мелькает "public class" или "new function()"? Ну и что?
Надеюсь, вас концептуально не напрягает такое, например, использование "кошек" - " 12.345.GetType().ToString().Split('a')[0]; "?

maXmo... вообще-то, вся эта ООпафосная шелуха просто шелуха над старым добрым асмом: где-то сидят метаданные, где-то vtable, в куче – объекты, а остальное – куски кода – тела функций, а вызов как и раньше: запихнули параметры в стек и – call по нужному адресу.
Кто ж спорит-то? Набор инструкций х86 еще не скоро будет отменен за ненадобностью...
Только, почему такое пренебрежение к категорям ЯВУ вообще, и ООП в частности ("вся эта ООпафосная шелуха")?
Или вы - из т.н. "С-шников старой закалки", для которых - "Нет Бога кроме - Кернигана, а Ричи - пророк его!"?

З.Ы. вдогонку к предыдущему спичу - чем вам генерик-делегаты-то не угодили?
Что плохого в том, что в C#3.0 будет реализовано что-то типа этого?

NotGonnaGetUs... Возвращаясь к примеру кода из моего предыдущего сообщения:

Это вы, уважаемый, не на c#2.0 писали, наверное, а "внутри головы" (бывает такое и со мной в порыве "запальчивости").
На c#2.0 надо примерно, так:

З.Ы. то maXmo - ну вот, кода-то наворотили за 4 поста - 3 горы, а что толку?

NotGonnaGetUs...
А со мной не бывает :) Это код на с#2.0.
Во, блин... (и точно).
Как языки-то "вперед двинулись", не успеваешь за сокращением синтаксиса следить...
А "мод" еще "причитает" о соответствии "семантики" и "синтаксиса"...
По-моему как раз:
и "семантически", и "синтаксически" более адекватно выглядит, чем "старое-доброе" (ау, любителям ассемблера):

мод NotGonnaGetUsСмотрим пример
Да уж. Спасибо, такое ФП нам не надо.
Ну а, к примеру, какого бы "ФП" вам хотелось?
Я там, давеча, приводил примеры "выведения" лямбд "по-месту":
Чем это вам не "объявление функции"?

мод...
1 передача аргументов всех типов по значению
2 максимально ленивые вычисления
3 аргументы и значение любых типов (в т.ч. и функции)
4 динамический вызов по шаблонам (не путать с сигнатурой)
5 транзакционность
6 параллельность
Я, конечно, как NGGU, под столом кататься не собираюсь, только очень сильно подозреваю, что весь вышеперечисленный список (за исключением п.п. 1 и 4, да и то "с натяжкой") - суть характеристики среды компиляции/исполнения, а отнюдь не ЯВУ... (будь он хоть ООП, хоть ФП, хоть "динамически-скриптовый", как это сейчас популярно на примере Ruby).
Языку, как набору синтаксических выражений, абсолютно пофигу - в какую семантическую модель он "складывается" внутри среды компиляции/исполнения: объектную, функциональную, транзакционную, параллельную или "адресно-стековую"... (но, об этом уже 100 раз "перетиралось").

мод dejavewтолько очень сильно подозреваю, что весь вышеперечисленный список (за исключением п.п. 1 и 4, да и то "с натяжкой") - суть характеристики среды компиляции/исполнения, а отнюдь не ЯВУ
Нет, это все д. б. поддержано на уровне конструкций самого языка...
Ну вот, не могу я понять - как "на уровне конструкций самого языка" поддержать "параллельность" и "транзакционность" задачи поиска человека по имени, фамилии и году рождения в огромном мегаполисе?