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

ceo>Давайте определимся. Версия языка и платформи — это разние вещи. Просто так совпало что вторая версия C# и .Net виходят одновременно. Сейчс идет речь о версии языка. Т.е. выпустят раширение для компилятора и студии.

Несомненно разные. Но ведь еще не выпущен C# 2.0!

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

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

Можно

Автор: Igor Trofimov
Дата: 14.09.05

.

S> А также интересно, как там с конфликтами имен.
S>Просто может появиться великолепная возможность придавать интерфейсам дефолтные реализации и утилитные методы. Примерно так:
S>

S>public static string Concat(this IEnumerable self, string separator)
S>{
S>  StringBuilder sb = new StringBuilder();
S>  foreach(object o in self)
S>    {
S>      sb.Append(o); 
S>        sb.Append(separator); 
S>    }
S>    if (sb.Length > 0)
S>      sb.Length -= separator.Length;
S>}
S>

Да интерфейся это все фигня. Вот то что можно расширять запечатанные классы (такие как string), вот это вообще здорово!

S>И это даст возможность писать .Concat(";") для любого IEnumerable.

Ага. Только лучше не конкат, а ToString(";") или ToSeparatedString(";").

S>Для бизнес-объектов это великая штука. Вот были у нас объекты Customer. А теперь мы дописываем cборку Orders, и у Customer появляется коллекция .Orders.

Э... для не бизнес-объектов это тоже очень нужно. Ну, прикинь как здорово дописать к тем же IEnumerable<T> и T[] такие агреггирующие функции как Max(), Avg(), Select. Это в сочетании с запросами позволит работать со списками почти как на настоящем SQL-е.

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

AVK>> ИМХО лучше бы они ввели возможность прикладному программисту создавать что то подобное на основе базовой механики. Чтобы можно было делать не только sql-like, но и, к примеру, xpath-like код.
Это средство трансформации. xpath — тут не катит(очевидно комега это хорошо показала). XQuery слишком завязан на xml. Здесь же практически чистый ассоциативный oql.
Вобщем, реляционный view который почему-то, кому-то, и зачем-то не хватало в ООП.

VD>Полностью согласен. Хорошим решением было бы введение макросов в стиле Лиспа или как предложил uw в стиле Nemerle.
Так что там предложил? (Ссылку исправь, пожалуйста).

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

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

VD>Я тоже глянул. Не очень то специализированное. Обработка списков одна из самых часто встречающихся задач.

Вот именно что обработка! Здесь же только запрос в select-like стиле.

VD> К тому же это только сахар. Все переписывается в функциональный силь. Так что это встроенный DSL.

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

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

S>По крайней мере в сиомеге обсуждалось именно это. Там анонимный тип полностью определяется типами своих компонентов. При этом имена аргументов в расчет не принимаются — они всего лишь позволяют обращаться напрямую к компонентам, используя привычную точку. Была вроде также ограниченная совместимость этих типов, похожая на совместимость массивов. Ну, типа { string, string} можно привести к { object, object }.

В иеющемся компиляторе и спецификации это не так.

var x = new { X = 0, yield = 1 };
var y = new { Z = 0, yield = 1 };

Console.WriteLine(x == y);

Последняя строка выдает ошибку:

error CS0019: Operator '==' cannot be applied to operands of type 'LINQConsoleApplication1.Program.<Projection>f__0' and 'LINQConsoleApplication1.Program.<Projection>f__1'

А вот так:

var x = new { X = 0, yield = 1 };
var y = new { X = 0, yield = 1 };

Console.WriteLine(x == y);

прокатывает, но результат плачевный — False.

S>При этом также, как для дженериков, независимые одинаковые спецификации порождают один и тот же тип. Т.е. если у тебя в одном месте порождается {string, string} и кастится к object перед отдачей, то в другом месте ты сможешь снова откастить это к {string, string}.

В имеющемся компиляторе это невозможно. По спецификации тоже пишут, что безымянный тип недоступен.

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

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

M>примерно так:

M>

M>string a;
M>int b;

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

Возвращать из лямбд можно. Инициализировать ими списки тоже. Но вот описать тип функции ими не удастся.

Твой примет тоже не прокатывает. Но у полей есть имена, так что можно писать так:

var x = new { A = "one", B = 1 };
string a = x.A;
int b    = x.B;

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

AVK>Это из другой оперы.

Как сказать.

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

Это да.

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

Опять таки смотря как это будет реализовано. А вот что они сделали с кортежами мне очень не нарвится. Решение убогое и половинчатое.

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

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

Думашь, только в МС читают форумы посвященные стандартизации С++? К тому же уверен, что фишка уже реализована в других языках за долго до того как она попала в Дельфи.

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

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

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

Возможно.

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

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

У тебя странное понятие сахара. Итераторы по-твоему тоже сахар?

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

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

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

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

Тут уже любители С++ смогут на поном основании говорить о том к кого какие картиночки.

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

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

Ну, да... им нужны имена. Уроды, былин.

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

С какого интересно перепуга нельзя добавить в Dictionary конструктор принимающий new { Key = "...", Value = ... }?
AVK>

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

Дык коллекции то старые. Параметра нет. Вот и все.

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

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

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

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

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

Я уже проверил. Уроды они. Анонимные типы пока что < кортежи.

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

Ага, вот только экземляры даже одинаковые сравниваются по адерсам и:

var x = new { X = 0, yield = 1 };
var y = new { X = 0, yield = 1 };

Console.WriteLine(x == y);

возвращает False.

Ну, что за дебилы это разрабатывали? Ну, неужели нельзя было просто скомуниздить идею кортежей 1 в 1? И ведь в роде в это СиОмеге все грамотно было сделано! Может они просто недоделали?

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

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

Наоборот. list comprehension намного более узкое решение. Это как гигантский foreach. Синтаксический сахар над паттерном проектирования.

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

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

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

Видно. Просто в спецификации пара слов всего. А вот в компиляторе уже по более. Плюс два примера есть. Жаль что они слишком огромные. Но похоже это именно возможность заставить преобразовать код в АСТ и обратно. Какого хрена не сделать это для любой конструкции и не позволить делать преобразования во время компиляции я не знаю. А было бы удобно. Ну, да возможно и без того будет круто.

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

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

Ну, на операции я уже посморел. Чистое АСТ которое можно менять как хочешь. Только не понял как из него получить скомпилированный код.

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

TK>Expression trees используются в DLinq для генерации SQL запросов. т.к. это позволяет разобрать выражение вида

c => c.Name = "MyName"

и, на его основе создать выражение для WHERE в SQL.

Похоже не совсем. Похоже они используют эти синтаксические деревья для более сложных вещей. Например, они используются в:

System.Data.DLinq.QueryExtensions.Sum<T>(Query<T> seq, Expression<Func<T, Nullable<double>>> expr)

То ест предоставляют возможность создать динамический запрос.

Но сам DLinq — это синтаксический сахар который преобразует SQL-подобные выражения в банальный код в функциональном стиле. Вот пример из описания DLinq-я:

from c in customers, o in c.Orders
where o.OrderDate.Year == 2005
orderby o.Total descending
select new { c.Name, o.OrderID, o.Total }

преобразуется компилятором в следующий псевдокод:

customers.
SelectMany(c =>
    c.Orders.
    Where(o => o.OrderDate.Year == 2005).
    Select(o => new { k1 = o.Total, v = new { c.Name, o.OrderID, o.Total } })
).
OrderByDescending(x => x.k1).
Select(x => x.v)

Expression trees же позволяют построить АСТ кода. Упомянутое же АВК объявление — это возможность заставить компилятор вместо МСИЛ-а породить АСТ указанного лямбды. Например:

using System;
using System.Expressions;
using System.Query;

class Program
{
    static void Main()
    {
        // просто лямбда
        Func<int, int> lambda = x => x * x;
        Console.WriteLine(lambda); // выводит System.Query.Func`2[System.Int32,System.Int32]
        Console.WriteLine(lambda(2)); // выводит 4

        // лямбда преобразуемая в дерево выражений. 
        Expression<Func<int, int>> lambdaExpression = x => x * x;
        Console.WriteLine(lambdaExpression); // выводит |x| Multiply(x, x)
    }
}

Короче они козлы и опять придумывают новую терминологию. Поубивал бы за все эти дебильные CodeDom & Expression trees. Все это сто лет назвад называлось Абстрактное Синтаксическое Дерево (AST).



TK>Собственно preview версия C# 3.0 доступна для делающих — можно будет скачать и, посмотреть что к чему.

Ну, да... Я уже глянул. Вот только не понял как преобразовывать эти самые Expression trees в скомилированный код.

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

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

Это из серии у гого чего болит. До таких долекоидущих мыслей я даже не додумался.
О несостоятельности данной теории говорит и то, что деревья выражений не реализуют ISerializable и не помечены соотвествующим атрибутом (корочен не сериализуются).

Все же они созданы для метапрогарммирования с трансформацией АСТ и для генерации кода в рантайме.

AVK>Нет, этого не будет. Ты наверное неверно понял что это за штука. Никаких планов там нет, это просто описатель, по которому стандартная библиотека умеет емитом генерить код метода.

В Query ничего не эмитится. А как заэмитить код из деревьев выражений я пока не нашел. Но это точно должно быть возможно.

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

Деревья выражений для того и созданы. Только к запросам это не имеет отношения. Правда можно на них наплевать и генерировать код в рантайме. Возможно что при обращении к БД именно так и делается.

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

GZ>

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

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

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

Это точно никакого отношения к МСИЛ-у не имеет. Это АСТ. Просто компиляторп озволяет стрить его не вручную, преобразуюя лямбды в него.

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

VD>>Полностью согласен. Хорошим решением было бы введение макросов в стиле Лиспа или как предложил uw в стиле Nemerle.
GZ>Так что там предложил? (Ссылку исправь, пожалуйста).

Re: C3 3.0 что думают приверженцы ФЯ?

Автор: uw
Дата: 15.09.05

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

AVK>Вот именно что обработка! Здесь же только запрос в select-like стиле.

И? Это самая сложная операция требующая декларативности. А удалять или обновлять это можно предварительно скопировав в отдельный список.

VD>> К тому же это только сахар. Все переписывается в функциональный силь. Так что это встроенный DSL.

AVK>Ключевой момент DSL в том, что его можно менять под предметную область. А здесь ничего менять нельзя. Так что это нифига не DSL.

А работа со списками и есть та самая предметная область.

ЗЫ

Я вобще-то немогу понять почему foreach не вызывает никаких нареканий, а сделаный по его образу и подбию чуть более сложный Query вызывает.

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

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

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

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

Имелась ввиду дыра на уровне исходников, когда расширяющий метод подменяет метод класса. Все прояснилось, не подменяет.

Тогда другой вопрос — а если в области видимости находится несколько "расширителей"?

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

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

V>Имелась ввиду дыра на уровне исходников, когда расширяющий метод подменяет метод класса.

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

V>Тогда другой вопрос — а если в области видимости находится несколько "расширителей"?

Читай стандарт, пробуй. Какой смысл мне в испорченный телефон играть?

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


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

VD>Думашь, только в МС читают форумы посвященные стандартизации С++? К тому же уверен, что фишка уже реализована в других языках за долго до того как она попала в Дельфи.

Для Delphi это было необходимо для совместимости старой объектной модели с нетовской. Но эта фишка сразу всем понравилась.

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

ceo>>Сейчс идет речь о версии языка. Т.е. выпустят раширение для компилятора и студии.
AVK>На сайте сказано что это C# 3.0 (Orkas). Что такое Orkas объяснять надо?

Но, в настоящее время, работает это на текущей версии .NET 2.0 т.е. пока есть только компилятор реализующий нужный сахар.

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

V>Тогда другой вопрос — а если в области видимости находится несколько "расширителей"?

Будет ambiguous.

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

S> Для Delphi это было необходимо для совместимости старой объектной модели с нетовской. Но эта фишка сразу всем понравилась.

Думаю, что "совместимости старой объектной модели с нетовской" была только дополнительным побуждющим фактором. Или их дизайнеров языка зря платят зарплату. Такие изменения дожны серьезно продумываться.

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

TK>Но, в настоящее время, работает это на текущей версии .NET 2.0 т.е. пока есть только компилятор реализующий нужный сахар.

То что компилятор совместим с предыдущим фрэймворком не значит, что нет новго фрэймворка.

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

VD>Но сам DLinq — это синтаксический сахар который преобразует SQL-подобные выражения в банальный код в функциональном стиле. Вот пример из описания DLinq-я:

Это Linq этим занимается. Задача DLinq по полученному дереву сгенерировать SQL стейтменты которые уже будут передаваться в ADO.NET.

VD>Expression trees же позволяют построить АСТ кода. Упомянутое же АВК объявление — это возможность заставить компилятор вместо МСИЛ-а породить АСТ указанного лямбды.

Именно по этому AST и генерируются SQL запросы