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

AVK>Небольшое вступление.

computation expressions, как в F#
http://msdn.microsoft.com/en-us/library/dd233182.aspx

Расширеная поддержка туплов, множественное присваивание:

Tuple<int,string> F();

var (a, s) = F();

Компайл тайм рефлексия:

class F<TArg>
{
 void Method1(TArg arg1);
}
...
var info = typeOf(new F<string>()).Method1.arg1.Type.Name; // здесь генерится структура компилятором, в которой будет вся инфа о классе

Assert.AreEqual("string",info);

Расширеная поддержка выражений:

Expression<Func<IEnumerable<int>>> array = GetValues();

Expression e = `foreach(var item in #array) { DoSomething(item)}`;

e.Compile().Invoke();

Разворачивается в обычные экспрешны.

Анонимные классы:

var b = true;
using(var f = new IDisposable { void Dispose { b = false; } } )
{

}

Здесь по аналогии с лямбдами генерируется класс по описанию.

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

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

Tom>>А что не так с x64 если не секрет?

X>Полное отсутствие оптимизаций

я не знаток во внутренних оптимизациях .net'а, но мне казалось, что TCO работает только в x64;
чем не оптимизация?

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

X> 2) сборка в LOH с релокацией

А в 4.5 разве это не появилось ?

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

IT>>И чего оно такого дублирует?
AVK>Обычные классы с виртуальными методами.

Так можно договориться до того, что любой класс дублирует функциональность object.

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

X>Сецчас язык настолько опережает рантайм, что дальнейшие "мажорные" фичи — это рост колосса на глиняных ногах.
X>С точки зрения людей, не знакомых с кухней MS, C# и .NET CLR — даже не муж и жена, а вообще один человек.
X>Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC

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

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

X>Сецчас язык настолько опережает рантайм, что дальнейшие "мажорные" фичи — это рост колосса на глиняных ногах.

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

X>Так что все силы надо пускать на CLR — многоплатформенность, нормальные оптимизации, наконец-таки нормальный x64, внятный и предсказуемый GC

Многоплатформенности ждать не стоит, остальное вполне.

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

Tom>А что не так с x64 если не секрет?

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

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

S>При чём тут C#?

Чуть ниже я объяснил причём:

M>>Вообще, у C# довольно помоечный синтаксис работы с классами: вместо элегантных конструкций с именами типов приходится влезать чуть ли не в ассемблер: Класс.ДайСвойТип().ШаманскиеФункции.... отстой полнейший. Нужен синтаксис сразу на уровне "Класс", типа "Класс.ДайПропертиСАтрибутом(Атрибут)".

Без поддержки языка это не делается в принципе.
Путь C# будет "чуть более бейсиком" — упрощать низкоуровневый код. Сей и Сипипей мы уже наелись, пора как-то подымать уровень!

M>>Улучшить оператор AS: нечасто, но изрядно упрощает бойлерплэйт a = b as SomeType; if (a != null) ....; Вариант: when(b = a as SomeType) { юзаем b }

S>a.WhenIs<SomeType>{b=>юзаем b }

Костыли не интересны ввиду своей неэлегантности. Тот же ?: тоже выражается через if'ы, тем не менее, его ввели в язык.
И потом, можно провести анализ кода — поискать наиболее употребимые конструкции и решить как их можно упростить.

M>>Упрощ. иниц. объекта помимо new: var z = GetObject() <= { filed = 4, field2 = 5 }
S>Зачем?

Можно не вводить, если реализуют паскалевский with.
Синклер, если следовать логике Смоллтока, можно вообще оставить две вещи — присвоение и посылка сообщения. Но люди почему-то хотят иметь более "читаемый" код.

M>>Duck typing ака MapAs: приводить объект к интерфейсу, если он совместим по методам.
S>Реализовано в библиотеках — BLToolkit смотрели?

эээ... Я БЛТ юзаю только для БД. Надо будет глянуть, пасип

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

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

Извиняюсь, поторопился. Как в анеке: "Да пошла она со своей солью!". Просто язык как был низкоуровневой "си-подобной" фигнёй, так за 10 лет и не вырос. И главное, разрабы думают о каких-то "киллер-фичах", хотя у языка хватает и "обычных" улучшений — посмотри сколько в ветке собралось "мелочей". Уверен, никто их даже читать не будет — они, видите ли, не подходят для маркетоидных испражнений. Вот так яснее моё негодование?

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

M>Уверен, никто их даже читать не будет

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

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

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

X>>Очень поддерживаю. Нужна возможность декларировать интерфейс создания семейства объектов.

Ц>Это просто идея, и я не уверен в её состоятельности. Я на самом деле очень люблю неизменяемые типы, но таким образом даже от левого класса нужна поддержка такого специфического конструирования объекта, хотя это забота уже самого типа. Поведение принято решать через методы интерфейсов. Быть может, здесь лучше использовать фабрику объектов, которая знает как создать неизменяемый объект?

Фабрика в этом случае — это лишний класс на пустом месте. Все правки шарпа как раз и нацелены на уменьшение количества "лишнего" кода.Так что считаю, что идея очень правильная. Сам тоже об этом думал: http://blogs.byte-force.com/xor/archive/2004/11/04/333.aspx


У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx

Здравствуйте, Аноним, Вы писали:

А>У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx

О, хорошее слово «лженерики». «Лженерики» — это дженерики в Джаве.

вот еще вспомнилось, чего нехватает в C#

сейчас нельзя написать структуру с автопропертями

struct Foobar {
  public string Name {get; set;}
  public Foobar(string name) {
    Name = name;
  }
}

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

Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.

class CollectionItem {}
class Collection 
{
    protected virtual CollectionItem CreateItem() {...}
}



class MyCollectionItem: CollectionItem {}
class MyCollection 
{
    protected override MyCollectionItem CreateItem() {...}
}

В Java есть, AFAIR.

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

K>сейчас нельзя написать структуру с автопропертями
Можно

struct Foobar {
  public string Name {get; set;}
  public Foobar(string name): this() {
    Name = name;
  }
}

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

Q>Здравствуйте, Аноним, Вы писали:

А>>У меня еще была идея, что в лженериках был бы полезен thistype: http://blogs.byte-force.com/xor/archive/2009/09/15/thistype-for-generics.aspx

Q>О, хорошее слово «лженерики». «Лженерики» — это дженерики в Джаве.

На планшете вечно мимо кнопок промахиваюсь. Иногда — удачно.

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

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

J>Хз, можно ли это красиво сделать без правок в CLR, но фича полезная и логичная была бы.


J>

J>class CollectionItem {}
J>class Collection 
J>{
J>    protected virtual CollectionItem CreateItem() {...}
J>}



J>class MyCollectionItem: CollectionItem {}
J>class MyCollection 
J>{
J>    protected override MyCollectionItem CreateItem() {...}
J>}
J>

J>В Java есть, AFAIR.

имхо, для такого кода хорошо подходят дженерики

Блоки итераторов в лямбда выражениях!!

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

K>имхо, для такого кода хорошо подходят дженерики

Ну и получится у класс с N дженерик параметрами, N — количество виртуальных не-void методов. Не страшно?

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

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

K>>сейчас нельзя написать структуру с автопропертями
S>Можно
S>

S>struct Foobar {
S>  public string Name {get; set;}
S>  public Foobar(string name): this() {
S>    Name = name;
S>  }
S>}
S>

спасибо : ) не знал про этот странный нюанс.
но все равно есть, что улучшать : )
было бы здорово, чтобы вообще без дополнительного вызова.