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

AVK>>2) Расширяющие методы (Extension methods). Хитрая штука. Это получается так:
GZ>

GZ>//я написал
GZ>public MyCryptoClass
GZ>{
GZ>public Crypt(){CryptForSecure();};
GZ>}
GZ>//доброжелатель ответил
GZ>public static class Extensions
GZ>{
GZ>public static Crypt(this MyCryptoClass class){SaveForUnsecure();};
GZ>}
GZ>

GZ>Занятненько.

Что ты этим кодом хотел сказать?

GZ>[imho]Возможно даже не для сериализации, а для ленивых вычислений.

С этим и обычные лямбда-функции справяться, никакой необходимости в этом случае в кодогенерации нет. Я тут покумекал и кажется понял зачем они эту штуку ввели. Это нужно чтобы эффективно реализовывать на базе Query Expressions трехзвенные решения. На клиенте просто укатываем запрос в такой expression tree, а на сервере получаем готовый код, который не надо интерпретировать.

GZ> Особенно для Query это очень уместно. К тому-же обычно такие запросы можно оптимизировать. Возможно это будет редактируемый план выполнения.

Нет, этого не будет. Ты наверное неверно понял что это за штука. Никаких планов там нет, это просто описатель, по которому стандартная библиотека умеет емитом генерить код метода. Логика там примитивнейшая (скорее всего просто в ресурсах компилятор сохраняет скомпилированный IL-код). Очень вряд ли прикладной программист сможет вмешаться в процесс генерации этого кода. По крайней мере в текущей реализации этого точно нет.

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

AVK>>2) Расширяющие методы (Extension methods). Хитрая штука. Позволяет объявлять статические методы с параметром this и привязывать их в качестве метода экземпляра к существующим классам.

iT>О! Это здорово! Это то, что в Delphi последней назвается helper-классом.

Да, похоже. Хотя шарповский вариант более lightweight что ли.

AVK>>Любители функционального стиля будут довольны. Хотя возможность творить на этой базе извраты (особенно если совместно с дженериками) меня пугает.

iT>Мда, извраты с печальными результатами (что без поллитры не разберешься) мы уже видели для C# 2.0.

Ну пока это именно извратства, а не попытка сделать что то непредусмотренное.

AVK>>5. Анонимные типы. Проистекают из возможностей в п.1 и п.4. На основании объектного инициализатора выводится тип.

iT>Что-то вроде tuples.

Они и есть.

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

iT>>Мда, извраты с печальными результатами (что без поллитры не разберешься) мы уже видели для C# 2.0.

VD>Блин, Дельфи и Васики живы и ждут всех кто не привык напрягать извилины.

А для Васика тоже новую версию выложили с похожими изменениями. Я, правда, не смотрел.

VD>Они и есть. У МС духу не хватает назвать скомунизженные парадигмы своими именами.

Хватило. В какой то из док это слово даже проскакивало.

iT>>Imho, полный изврат.

VD>Может дял начала разобраться и попробовать?

С утречка думал — все таки слишком узкоспециализированная штука. ИМХО лучше бы они ввели возможность прикладному программисту создавать что то подобное на основе базовой механики. Чтобы можно было делать не только sql-like, но и, к примеру, xpath-like код.

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

AVK>>В качестве основной цели задекларированна поддержка функционального стиля.
ZEN>Резюме.
ZEN>Язык программирования явно тяготеет к разговорному английскому.

Неа. Функциональный стиль это скорее математика и лямбда-исчисление.

ZEN> А оно надо?

Время покажет.

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

ceo>Сейчс идет речь о версии языка. Т.е. выпустят раширение для компилятора и студии.

На сайте сказано что это C# 3.0 (Orkas). Что такое Orkas объяснять надо?

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

F>>>Здесь страничка появилась "Visual C# Home > Future Versions". Среди прочего там лежит "csharp 3.0 specification.doc" — набросок новых фич в третьей версии.

_FR>>Вы только оглавление посмотрите:

VD>Хачу, хачу, хачу... (с) девочка у зациклившегося проирывателя произносящего фразу "хочешь я расскажу тебе сказку".

VD>В общем, дайте телефон Хегельберага пойду его трясти чтобы альфу дал.

Кое-что уже можно пробовать:
The LINQ Project

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

AVK>>2) Расширяющие методы (Extension methods). Хитрая штука. Это получается так:
GZ>

GZ>//я написал
GZ>public MyCryptoClass
GZ>{
GZ>public Crypt(){CryptForSecure();};
GZ>}
GZ>//доброжелатель ответил
GZ>public static class Extensions
GZ>{
GZ>public static Crypt(this MyCryptoClass class){SaveForUnsecure();};
GZ>}
GZ>

GZ>Занятненько.

А Extensions::Crypt разве перекрывает MyCryptoClass::Crypt? Если да — от это дыра

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

AVK>>1) Неявно типизированные локальные переменные (implicitly typed local variable). То о чем долго говорили большевики в форуме философия. Даже ключевое слово народ там угадал.

VD>Ха! Большивики еще говорили о том, что разумно было бы ввести неизменяемые локальные переменне.

Это из другой оперы. Большевики еще, к примеру, очень долго говорили, что одним из самых больших недостатков императивных возможностей шарпа является отсутствие возможности подключения реализаций. Тем не менее воз и ныне там.

VD>А вообще, МС как всегда реализует чужие идеи называя их своими инменами. Это дело в исходном виде называлось "вывод типов" (type inference).

Вот бы еще они mixins скоммунизьмили.

VD>Вот и ответ на все несоотвестия. Таки теперь мы будет иметь нормальный ОО-синтаксис вызова методов расширения. В общем, объект все что качается, если не качается, то раскачивается и признается объектом.

Ну, надо признать, что в Delphi.NET похожее уже есть.

AVK>>Сахар конечно, но забавно.

VD>Э... Не скажи. Это очень правильное решение. Это устраняет одно из серьезных несоотвествий. Теперь никакой педант не скажет, что ToString() ошибка, так как нельзя сделать ToMyClass().

VD>Единообразие много стоит.

ХЗ. ИМХО вопрос культуры программирования. С точки зрения архитектурных проблем это ничего не дает. А меня это волнует в первую очередь.

AVK>>Обсуждается необходимость расширяющих свойств, событий и операторов, но пока такое не поддержвается.

VD>Логично было бы позволить добавлять любые типы членов кроме пожалуй перменных.

Возможно, как с дженерик-свойствами, есть какие то синтаксические проблемы. Т.е. для методов добавление модификатора к параметру естественно, а вот со свойствами и событиями уже не так очевидно и требует сурового перетряхания грамматики. А вот почему операторы не добавили — ХЗ.

AVK>>3) Лямбда-выражения. Выражения, служащие для написания программ в функциональном стиле. Вобщем то в 2.0 анонимные методы очень на это похожи, но в 3.0 сделана попытка преобразовать внешний вид к более функциональному стилю. Для этого введен новый токен — =>.
AVK>>Пример:
AVK>>

AVK>>delegate R Func<A,R>(A arg);

AVK>>...

AVK>>Func<int,int> f1 = x => x + 1;            // Ok
AVK>>Func<int,double> f2 = x => x + 1;        // Ok
AVK>>Func<double,int> f3 = x => x + 1;        // Error
AVK>>

VD>То есть это только сахар?

Все, что сейчас описано это сахар, потому что существующая реализация работает на 2 фреймворке.

VD> Хотя конечно и это полезно. Уж больно много места занимает никчемное ключевое слово delegate и описание параметров анонимного метода.

+1

VD>Однако для полноценного применения функционального стиля нужно сделать еще два шага. Во первых ввести передачу лямд без делегатов, чтобы можно было делать лямбда-преоразования и соответсвенно строить методы из кусков,

Возможно можно будет что то соорудить на базе expression tree.

AVK>> Хотя возможность творить на этой базе извраты (особенно если совместно с дженериками) меня пугает.

VD>Гы. Не боись. У функционального стиля большой потенциал. А ламерам останется Васик.

Не факт . В нем тоже может многое из этого появится. Надо глядеть. Да и потом — для любителей извратов есть С++/CLI

VD>Ё! И об этом говорили большивеки в "Философии".

Как то прошло мимо моего глаза.

VD>Гы. Это же они и есть — tuple-ы.

VD>Так что предыдущий пример должен будет выглядеть так:
VD>

VD>var dict = new Dictionary<string, int>
VD>{
VD>  new { "one", 1 }, new { "two", 2 }, new { "three", 3 }
VD>};
VD>

Не, это работать не будет. Во-первых это просто неверный синтаксис, правильно так:

var dict2 = new Dictionary<string, int>
{
    new { Key = "one", Value = 1 },
    new { Key = "two", Value = 2 },
    new { Key = "three", Value = 3 }
};

Потом, компилятор создаст свой класс, а в collection initializer нужно тот тип, который T в реализованном ICollection<T>. Т.е., в случае Dictionary это KeyValuePair. Текущий компилятор на такой код говорит следующее:

TupleDic.cs(15,9): error CS0029: Cannot implicitly convert type 'Test.<Projection>f__0' to 'System.Collections.Generic.KeyValuePair<string,int>'

Да, еще компилятор не понимает явную реализацию интерфейсов, так что даже мой вариант не компилируется, говорит что:

TupleDic.cs(7,42): error CS1501: No overload for method 'Add' takes '1' arguments

Хотя в спецификации написано, то он будет искать Add именно у ICollection<T> (и иногда так и делает, судя по предыдущей ошибке). ИМХО просто баг.

VD>А с чего он взял, что Name и Price — это свойства, а не поля?

С того, что так написано в спецификации.

VD>Не. Ты точно не правильно понял. Анонимные типы == кортежи. Кортежи сравниваются по значению и должны мочь использоваться везде где применимы длругие типы. Но должен быть синтаксис описания анонимных типов без декларации. Тогда их можно будет использовать как возвращаемые занчения функций и как параметры функций. Корче это неотемлемая часть функционального стиля!

Может быть. Но если ты приведешь компилируемый пример, тогда я поверю. Пока же, по текущей спецификации, это не работает. Единственное — компилятор на одинаковые объявления генерирует один и тот же класс. Это видно в самой последней строчке примера.

AVK>>ИМХО изврат редкостный. Насколько это будет полезно я пока ответить затрудняюсь.

VD>...хотя очень уж смахивает на list comprehension из таких языков как Питон, Хаскель и т.п. Вообще штука забавная, но уж больно диковинно реализованно. Хотя я могу ошибаться. Тут нужно попробовать на практике.

ИМХО слишком узкоспециализированно.

VD>Гы. Темнота. Это такой изращенческий способ открыть дверь в мир лямбда-исчислений, а точнее лямбда-конверсий, т.е. в мир комбинаторной логики. Дело в том, что делегаты далеко не самый эффективный способ работы с функциями. Они приводят к динамическому полиморфизму, что как минимум медленее нежели статический. Теория лямбда-конверсий подразумевает, что над методами можно производить разные вычисления какбудто это объекты. Таким образом можно из одних методов создавать другие. Причем результат может быть очень и очень забавным.

Но из текущей спецификации ничего такого не видно.

VD>Про операциями над этими выражениями ничего не сказано?

Нет. Там почти ничего не рассказано про эту фишку.

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

M>это не все что может tuple
M>тогда при таком синтаксисе логично было бы уметь ее возвращать из функций, и присваивать списку переменных.
M>примерно так:

Тогда скорее так

string a;
int b;

(a, b) = ("one", 1 );

или так

(string a; int b) = ("one", 1 );

или еще лучше так

(var a; var b) = ("one", 1 );

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

V>А Extensions::Crypt разве перекрывает MyCryptoClass::Crypt? Если да — от это дыра

Нет тут никакой дыры. Не забывай, что это синтаксический сахар.

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

VD>>Единообразие много стоит.
S>Интересно, можно ли в качестве this аргумента использовать интерфейс? А также интересно, как там с конфликтами имен.

Читай спецификацию. Пересказ то краткий.

V>А Extensions::Crypt разве перекрывает MyCryptoClass::Crypt? Если да — от это дыра
Нет тут никакой дыры. Не забывай, что это синтаксический сахар.

Таже вроде бы написано:

26.2.3 Extension method invocations
...
if the normal processing of the invocation finds no applicable instance methods (specifically, if the set of candidate methods for the invocation is empty), an attempt is made to process the construct as an extension method invocation.

Так, что, действительно нет дыры.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

Sorry, не сразу прочел
С уважением, Gleb.

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

AVK>Нет тут никакой дыры. Не забывай, что это синтаксический сахар.
Эдак весь C# можно считать синтаксическим сахаром для CLI.

С уважением, Gleb.

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

AVK>>Нет тут никакой дыры. Не забывай, что это синтаксический сахар.
GZ>Эдак весь C# можно считать синтаксическим сахаром для CLI.

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

В этом случае как украинец прийду с салом и горилкой

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

AVK>Нет, этого не будет. Ты наверное неверно понял что это за штука. Никаких планов там нет, это просто описатель, по которому стандартная библиотека умеет емитом генерить код метода. Логика там примитивнейшая (скорее всего просто в ресурсах компилятор сохраняет скомпилированный IL-код). Очень вряд ли прикладной программист сможет вмешаться в процесс генерации этого кода. По крайней мере в текущей реализации этого точно нет.

Exercise 4 – Using Lambda Expressions to Create Expression Trees
In addition to treating data as objects, LINQ provides the ability to treat expressions as data at runtime. LINQ defines a new type, Expression<T>, that represents an expression tree, an in-memory representation of a lambda expression. Expression trees allow developers to treat lambda expressions as data, allowing for inspection and modification of lambda expressions in code. This feature will be used to enable an ecosystem of third-party libraries that leverage the base query abstractions that are part of LINQ. For example, a database access implementation might leverage this facility to translate expression trees into suitable query statements for a particular kind of database.

Использование:

static void Main(string[] args)
{
     Expression<Func<int, bool>> filter = n => (n * 3) < 5;

     BinaryExpression lt = (BinaryExpression) filter.Body;
     BinaryExpression mult = (BinaryExpression) lt.Left;            
     ParameterExpression en = (ParameterExpression) mult.Left;            
     ConstantExpression three = (ConstantExpression) mult.Right;
     ConstantExpression five = (ConstantExpression) lt.Right;
                        
     Console.WriteLine("({0} ({1} {2} {3}) {4})", lt.NodeType, 
              mult.NodeType, en.Name, three.Value, five.Value); 
}

Есть у меня сомнение, что это гонится из чистого CLI кода. Хотя чем черт не шутит. Надо смотреть.

С уважением, Gleb.

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

TK>Мало того, это все уже в студию интегрировано

Уже глянул. Хреново оно интегрировано. Они создали только таргеты для мсбилда, а синтаксис студия не знает. Так что на лямбды ругается по полной.

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

AVK>А для Васика тоже новую версию выложили с похожими изменениями. Я, правда, не смотрел.

Как мне жалко васиковцев . Ну, да мноие из них с VB 6.0 не слезли. Теперь похоже и не слезут.

VD>>Они и есть. У МС духу не хватает назвать скомунизженные парадигмы своими именами.

AVK>Хватило. В какой то из док это слово даже проскакивало.

Это видимо ошибка. Устранят к релизу.

AVK>С утречка думал — все таки слишком узкоспециализированная штука.

Я тоже глянул. Не очень то специализированное. Обработка списков одна из самых часто встречающихся задач. К тому же это только сахар. Все переписывается в функциональный силь. Так что это встроенный DSL.

AVK> ИМХО лучше бы они ввели возможность прикладному программисту создавать что то подобное на основе базовой механики. Чтобы можно было делать не только sql-like, но и, к примеру, xpath-like код.

Полностью согласен. Хорошим решением было бы введение макросов в стиле Лиспа или как предложил uw в стиле Nemerle.

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

iT>>Что-то вроде tuples.

AVK>Они и есть.

Похоже что не совсем. В классических ФЯ tuples можно использовать для описания типов возвращаемых значений функций. А как это сделать в шарпе? Получается, что их можно использовать тлько в лямбдах и при описании вложенных структур (в списках и т.п.). Что не есть гуд.