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

VD>Почему не ожидал? Это наверно ты путашь мое отношение к статической типизации и наличие явной декларации типов.

А есть ли жизнь без интелисенса?

VD>ЗЫ

VD>Уверен, что после выхода C# 3.0 синтаксис delegate(...){ ... } быстро будет забыт.

Я пока подозреваю, что в C# нового синтаксиса не будет. Проще новый язык разработать без старого багажа. Типа Z#, а C# объявить устаревшим Это как раз вписывается в популярную в нынешней индустрии схему "раз в пять-сем лет — новый язык".

VD>Пока вообще можно добавлять только методы. Как я понимаю вопрос о свойствах и событиях обсуждается.

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

События не очень понятно как можно расширять — только если за счет других событий целевого класса. Оно в реальности-то пригодится?

А вот свойства и операторы — это действительно было бы полезно..

По мне, так лучше бы ввели ключевое слово и приписывали бы его к самому классу, а то как сейчас — сам класс получается вообще не при чем...

iT>По мне, так лучше бы ввели ключевое слово и приписывали бы его к самому классу, а то как сейчас — сам класс получается вообще не при чем...

к классу-то как раз и неинтересно приписывать...

т.к. хочется добавлять внешние методы и к готовым классам (библиотечным, чужим и т.д.).

DG>к классу-то как раз и неинтересно приписывать...
DG>т.к. хочется добавлять внешние методы и к готовым классам (библиотечным, чужим и т.д.).

Не, ты не понял. Я имею в виду что-то наподобие следующего:

public class extension StringExtr : string
{
     // Модификатор доступа вообще говоря для расширений не нужен

     bool IsEmpty  // Это расширение свойством. 
     {
        get { return this != null || Length == 0; }
     }

     int ToInt32(int defaultValue) // Это расширение методом
     {...} 
}

Т.е. во-первых явно сгруппировать члены, расширяющие конкретный целевой класс (сейчас их можно смешать в один static класс Util и все.)

Во-вторых, Перенести "новый" синтаксис в определение самого класса-расширителя, а не метода.
"Условное" наследование от string означает, что this имеет тип string (хотя может быть null для reference-типов), а дополнительное ключевое слово extension подразумевает, что экземпляры StringExtr создавать нельзя (как static), и что нужно применять этот класс как набор расширений для string.

iT>Во-вторых, Перенести "новый" синтаксис в определение самого класса-расширителя, а не метода.
iT>"Условное" наследование от string означает, что this имеет тип string (хотя может быть null для reference-типов), а дополнительное ключевое слово extension подразумевает, что экземпляры StringExtr создавать нельзя (как static), и что нужно применять этот класс как набор расширений для string.

но тогда придется бороться с объявлением полей внутри такого класса, создания экземпляра такого класса и т.д.

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

DG>А самому подумать?

О том, что ты незнашь значений слов? Не, я не телепат.
На будущее, "поле" — это переменная-член класса.

DG>конечно, же я имел ввиду свойства.

Про свойства я тебе уже сказал.

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

iT>Непонятно, как они с синтаксисом будут решать. Для методов получилось удачно, лишних ключевых свойств не потребовалось.. А для свойств тех же?

Вариантов много. Или тот же this куда-нибудь всунуть. Или атрибутом указать.

iT>События не очень понятно как можно расширять — только если за счет других событий целевого класса. Оно в реальности-то пригодится?

Вот народ и думат надо ли...

iT>А вот свойства и операторы — это действительно было бы полезно..

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

iT>По мне, так лучше бы ввели ключевое слово и приписывали бы его к самому классу, а то как сейчас — сам класс получается вообще не при чем...

А он и не причем. Расширение может возидействовать сразу на несколько классов. Даже на интерфейсы.

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

DG>ню-ню, посмотрю я как, ты в большом проекте на каждый чих сможешь написать корректный Null-object.

Все грамотные программися сто лет как пользуются этим паттерном. Так что приобщайся.

DG>Взять тот же пример с возврастом:

DG>Как должен выглядеть Null-объект, чтобы корректно работали оба варианта:
DG>

DG>if (user.Age > 21)
DG>{
DG>  //bla-bla
DG>}
DG>if (user.Age < 16)
DG>{
DG>  //bla-bla
DG>}
DG>

Будет у тебя нал-объект попадать во второй диапазон. Что страшного?

DG>Во-вторых:
DG>как написать Null-объект, если исходный интерфейс не подразумевал null-возвраст?

Есть такая штука — проектирование. Очень полезная вещь.

DG>Вообще-то, в бизнес-логике null и пустой массив — это не одно и тоже

Ты видимо читашь что-то свое. Попробуй еще раз и не думай в этот момент о постороннем.

DG>ps
DG>и, вообще, авторитетом подавил, а не на один из моих вопросов, так адекватного ответа и не дал.

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

Попробуй на практике. Потом поделишся результатами.
Как и любой паттерн этот не безупречен и имеет свои недостатки. Под них нужно подстараиваться. Бывает что паттерн не применим или неудобен. Что же поделашь?

Я стараюсь вообще избегать ситуаций когда null являтся шатной ситуацией. Это разко упрощает код. Те же нал-объекты нужны тольк там где возможно отсуствие объекта. А во многих случаях это просто не нужно. В том же конфиге объект просто обязан присуствовать. Зачем там null?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А есть ли жизнь без интелисенса?

А кто тебе сказал, что его не будет? Вывод типов ведь есть? А занчит есть и типы. А раз они есть, то будет и ителисенс. Пока что его нет и это сильно напрягает. Но всему свое время.

ANS>Я пока подозреваю, что в C# нового синтаксиса не будет.

Да он уже есть. И я не вижу чтобы кто-то хотел от него отказаться.

ANS> Проще новый язык разработать без старого багажа.

Не, ну, нужно все же более трезво смотреть на реальность. Что проще? Он уже есть!

ANS> Типа Z#, а C# объявить устаревшим Это как раз вписывается в популярную в нынешней индустрии схему "раз в пять-сем лет — новый язык".

Дык есть C# 1.х, есть C# 2.х, и будет C# 3.х. Это три разных языка имеющие обратную совместимость сверху вниз. При этом ты можешь писать на C# 1.х используя компилятор и среду от 3.х. Что еще нужно? Тебя же никто не заставляет использовать неудобные или непонятные по твоему мнению констркции?

Я думаю, синтаксис лямбд уже не изменится. Хорошо бы чтобы анонимные типы стали полноценными tuple-ами (т.е. типами которые можно сравнивать при совпадении структуры). Так же хотелось бы, чтобы компилятор научился делать преобразования лямбд во время компиляции. Еще было бы здорово если деревья выражения можно было бы в рантайме и компайлтайме преобразовывать в код (после модификации). Все это дало бы неслыханную гибкость при впролне простом синтаксисе и позволило бы стать C#-у безусловным лидером среди языков общего назначения.

DG>но тогда придется бороться с объявлением полей внутри такого класса, создания экземпляра такого класса и т.д.

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

VD> Будет у тебя нал-объект попадать во второй диапазон. Что страшного?

страшно то, что результат должен был быть не такой.

если это было бизнес-правило, например, для интернет-магазина:
Если возвраст < 10, то показать рекламу детских игрушек.

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

И это ты называешь не страшно?

VD>Попробуй на практике. Потом поделишся результатами.

Пробовал. Очень громоздко и неудобно.
Кол-во всего кода возврастает на четверть.
Сопровождение усложняется раза в полтора, т.к. при изменении основного объекта, надо также менять и Null-ипостаси.

Речь идет о том, что Null-паттерн в C# реализовывать неудобно, в SmallTalk-е удобно, а в C# — неудобно.

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

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

VD>Дык есть C# 1.х, есть C# 2.х, и будет C# 3.х. Это три разных языка имеющие обратную совместимость сверху вниз. При этом ты можешь писать на C# 1.х используя компилятор и среду от 3.х. Что еще нужно? Тебя же никто не заставляет использовать неудобные или непонятные по твоему мнению констркции?

Да мне то, как раз, всё равно. А бедному Васе Пупкину *всё* нужно будет выучить. Ибо на собеседовании могут спросить...

Кстати, это бы еще позволило расширять статические члены класса.
Например, "засунуть" в DateTime статическое свойство TimeOfDinner Или расширить какой-то enum более дружественным, типизированным методом Parse.

Вообще позволило бы чуть-чуть "дописывать" стандартную библиотеку под нужды системы. Сахар, конечно, но очень сладкий и в целом безопасный.

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

VD>>>ФП же как раз отлично вписывается в ООП. Ведь и сами функции могут быть методами объектов, и объекты параметрами функций. Более того функции высшего порядка позволяют абстрагировать алгоритм от конкретных типов объектов.
GZ>>Если методы объектов выполняют ограничения ФП.
VD>Какие еще ограничения? Ты о чем?
Пока оставлю эту тему. Только ламеры читают help. Нескольких часов мутузанья клавиатуры и компилятора, не дали результата. А сейчас заглянул в спецификацию:

Note
The PDC 2005 Technology Preview compiler does not support lambda expressions with a statement block body. In cases where a statement block body is needed, the C# 2.0 anonymous method syntax must be used.

Так что, пока беру слова назад.

GZ>> Хочешь генери новые классы. Хочешь используй неименованные типы(приводя их к именнованным). Чего тебе не хватает?
VD>Удобства.
R# тебя спасет?

GZ>> Да, это не Лисп. Кое что, в построении отдельного языка, будет труднее сделать. Но в рамках C# описать язык вполне можно. Особенно, если это будет C# синтаксис. Он тебе недостаточен?
VD>Я не смог уловить смысла этого абзаца.
DSL — слишком абстрактное понятие. Не хотелось бы затевать флейм (который, к тому-же, уже был здесь не раз).

VD>>>Ты просто привык к одному взгляду на мир. А мир более разнообразен.
GZ>>Грешен.
VD>Да, но чтобы это понять нужно просто попрограммировать с использованием новых возможностей, а потом попробовать жить без них.
VD>Вот в этом и проблема. Я тоже долго жил в этом мире, но понял, что другой мир имеет свои приемущества. Но и этот новый мир не идеален. А вот когда оба мира доступны в рамках одного языка, то жить становится удобно и приятно.
Напоминает слова проповедника.
Я жил в темном мире, занимался сексом, курил, пил, дизассемблировал PowerBuilder и писал классы. Но однажды во сне ко мне пришел Haskell Curry и сказал — лямбда есть комбинаторика, и я прозрел. Я бросил старый темный мир погрязший в грехе. Теперь я живу в светлом мире, отшельником в келье среди лесной чащи, ем один горох, и пишу на Лисп. Вот оно счастье нирваны.


GZ>>Именно. Не в бровь, а в глаз. delegate — это объект.
VD>Ну, заявление что делегат — это объект слишком натянуто. Для компилятора это всего лишь ссылка на функцию — примити.
GZ>> Притом объект с состоянием.
VD>Что? У самого делегата состояния нет. Это всго лишь указатеь. А в языке вообще ссылка на метод (безтелесная).
GZ>> Ты знаешь как его можно сделать без состояния?
VD>У него нет состояния. Состояние может быть у ассоциированного объекта, но это не одно и то же.
Имеется ввиду именно анонимный делегат. А у него есть состояние в виде локальных переменных. А следовательно, это нужно решать, старая реализация в виде анонимных делегатов мне, кажется, не подойдет.

GZ>> Реформировать процедуру чтобы сохранять состояние в параметрах? Тогда получается беспредел с рекурсией(если эта шняга работает только в рамках процедуры, а то еще больше интересного).
VD>Есть куча работ по комбинаторной логике и по преобразованию функций. Математически доказоно, что функции можно гибко переписывать во время компиляции. Многие ФЯ делают это без проблем и достигают очень нехилой производительности.
VD>Так что производительность упирается в качество реализации компиляторов (как языков, так и джита). И рано или поздно компиляторы дотнета научатся оптимизировать функцональный код.
Ага. Правда при условии, если фукнции можно представить как лямбда-термы. Иначе возможности оптимизации существенно сужаются. А у нас тут в statement block body может твориться все что угодно.


GZ>>Absolutly right. Тело функциональной программы — это граф. И его надо оптимизировать.
VD>Это, извини, чушь. Функциональные программы — это программы. Их моно представить как угодно. Есть стековые машины. Есть основанные на свертке графов, но они тоже по сути используют стэк. Ну, а что до компилируемых ФЯ, то в большинстве случае код после преобразований превращается в машинный (или IL). Так что никаких пробем тут нет.
Хорошо, скажу по другому. Хотелось бы оптимизировать.

VD>и будет здесь банальный рекурсивный вызов. Ну, и так как код написан бездумно, то будет переполнение стека в виду вечной рекурсии. Линивых вычислений в Шарпе ведь нет.
Поскольку нет оптимизации как таковой, то и ленивых вычислений(в самом высоком смысле этого слова) нет. IMHO А вот то что рекурсия так долбануто сделана — это плохо. Я сразу что-то прогнал про это, потому и спросил. Испугался что ее вообще нет.

GZ>>Мне интересен вопрос, как они это сделают?
VD>Ести тебе серьезно интересен этот вопрос, то советую обратиться к научным работам по этому поводу.
Не-а. Я тоже послать могу. Мне нужна обзорная статья по оптимизации в функциональных языках. Чтобы прочел, и сразу просветленный. Сразу бы бросил пить и начал бы жрать горох. (а то мои знания ограничены "примерным" понимание graph rewrite ).

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

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

VD>> Будет у тебя нал-объект попадать во второй диапазон. Что страшного?

DG>страшно то, что результат должен был быть не такой.

Проектируй так чтобы должен был бы быть такой.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Да мне то, как раз, всё равно. А бедному Васе Пупкину *всё* нужно будет выучить. Ибо на собеседовании могут спросить...

От лишних знаний еще никто не погибал. А то что ламеры будут отсеиваться — это хорошо.

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

GZ>R# тебя спасет?

R# это исследование. К тому же тесная интеграция с языком.

GZ>Напоминает слова проповедника.


GZ>Я жил в темном мире, занимался сексом, курил, пил, дизассемблировал PowerBuilder и писал классы. Но однажды во сне ко мне пришел Haskell Curry и сказал — лямбда есть комбинаторика, и я прозрел. Я бросил старый темный мир погрязший в грехе. Теперь я живу в светлом мире, отшельником в келье среди лесной чащи, ем один горох, и пишу на Лисп. Вот оно счастье нирваны.
GZ>

Не не так. Теперь у меня есть два мира, так что я занимаюсь сексом, курю, пью и т.п. но еще и колюсь.


GZ>Имеется ввиду именно анонимный делегат.

Метод, наверно.

GZ> А у него есть состояние в виде локальных переменных. А следовательно, это нужно решать, старая реализация в виде анонимных делегатов мне, кажется, не подойдет.

Состояние есть у любого метода. Так что ничго нового.

GZ>Ага. Правда при условии, если фукнции можно представить как лямбда-термы. Иначе возможности оптимизации существенно сужаются. А у нас тут в statement block body может твориться все что угодно.

Компилятор приципиально оперирует AST. Так что никаких проблем у него нет. Деревья выражений — это и есть AST. Так что все пучком.

GZ>Хорошо, скажу по другому. Хотелось бы оптимизировать.

Со временем будут и оптимизаторы. Про Феникс слышал? Вот в нем будут еще те возможности по оптимизации. Да и на уровне ЯП можно все что нужно сделать.

VD>>и будет здесь банальный рекурсивный вызов. Ну, и так как код написан бездумно, то будет переполнение стека в виду вечной рекурсии. Линивых вычислений в Шарпе ведь нет.
GZ>Поскольку нет оптимизации как таковой, то и ленивых вычислений(в самом высоком смысле этого слова) нет. IMHO

Это не связанные вещи. Линиые же вычисления легко достигаются за счет использования итераторов.

List<int> list = new List<int> { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int i = 0;
var lazyList =
                from elem in list
                select ++i;

Console.WriteLine("i = " + i);

foreach (int x in lazyList)
     Console.WriteLine("x = " + x + " i = " + i);

Console.WriteLine();

foreach (int x in lazyList)
{
    if (x > 15)
        break;
    Console.WriteLine("x = " + x + " i = " + i);
}

Console.WriteLine();

foreach (int x in lazyList)
     Console.WriteLine("x = " + x + " i = " + i);

Результат:

i = 0
x = 1 i = 1
x = 2 i = 2
x = 3 i = 3
x = 4 i = 4
x = 5 i = 5
x = 6 i = 6
x = 7 i = 7
x = 8 i = 8
x = 9 i = 9
x = 10 i = 10

x = 11 i = 11
x = 12 i = 12
x = 13 i = 13
x = 14 i = 14
x = 15 i = 15

x = 17 i = 17
x = 18 i = 18
x = 19 i = 19
x = 20 i = 20
x = 21 i = 21
x = 22 i = 22
x = 23 i = 23
x = 24 i = 24
x = 25 i = 25
x = 26 i = 26

GZ>>>Мне интересен вопрос, как они это сделают?
VD>>Ести тебе серьезно интересен этот вопрос, то советую обратиться к научным работам по этому поводу.
GZ>Не-а. Я тоже послать могу. Мне нужна обзорная статья по оптимизации в функциональных языках. Чтобы прочел, и сразу просветленный. Сразу бы бросил пить и начал бы жрать горох. (а то мои знания ограничены "примерным" понимание graph rewrite ).

Я закладок не делал. Если тебе в лом задать вопрос самому, то могу для тебя это сделать.

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

iT>Кстати, это бы еще позволило расширять статические члены класса.
iT>Например, "засунуть" в DateTime статическое свойство TimeOfDinner Или расширить какой-то enum более дружественным, типизированным методом Parse.

А чем хуже так:

static class EnumEx
{
    public static T Parse<T>(string str)
    {
        return (T)Enum.Parse(typeof(T), str, true);
    }
}

VladD2 wrote:

> ANS>Да мне то, как раз, всё равно. А бедному Васе Пупкину *всё* нужно
> будет выучить. Ибо на собеседовании могут спросить...
> От лишних знаний еще никто не погибал. А то что ламеры будут
> отсеиваться — это хорошо.

Неужели вы стали фанатом С++???!!!!

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

DG>Да, результирующий тип должен быть или тем же самым, для ссылочных,
DG>или Nullable<Type> для value-type-ов.

Точно, точно!

DG>но еще раз повторяю, что данный код совсем не равносилен исходному примеру, и может выдавать некорректный результат для многопоточного приложения

Это почему?

DG>или для кода с side-эффектами.

Ну, операторы ||, && ведут себя аналогино.