Я так понимаю, ты с какой-то целью запостил этот вопрос в два форума. Если в форуме по .NET будут обсуждаться фичи, то что будет обсуждаться тут?
Ну а по сути, языку не хватает нормальной кросс-платформенности от основного производителя, что убережет от проблем с совместимостью и лицензиями, которые привносит Mono.
Здравствуйте, kaa.python, Вы писали:
KP>Я так понимаю, ты с какой-то целью запостил этот вопрос в два форума. Если в форуме по .NET будут обсуждаться фичи, то что будет обсуждаться тут?
Тоже самое. Тут намного больше народа, который более менее разбирается в дизайне языков.
... << RSDN@Home 1.2.0 alpha 5 rev. 23 on Windows 8 6.2.9200.0>>
1. infoof 2. operator .?
выражение A.?B аналогично выражению A.B и раскрывается следующим образом в зависимости от результирующего типа выражения B (скобки ({ }) обозначают многострочный блок внутри выражения)
a. void
var a = A;
if (a != null)
a.B;
b. value-type
({
var a = A;
return a != null ? (Nullable<typeof(a)>)a.B : (Nullable<typeof(a)>)null;
})
c. ref-type
({
var a = A;
return a != null ? a.B : null;
})
3. возможность перегрузки функции по разнице value-type/ref-type
T? F<T>(T value) where T:value
{
..
}
T F<T>(T value) where T:class
{
..
}
выражение начинающее с точки раскрывается как лямбда. Точнее, если выражение содержит подвыражения начинающиеся с точки, то всё выражение раскрывается как лямбда
Скорее не про c# а про платформу в целом:
1) Обеспечить реальную кроссплатформенность платформы (без всяких поделок)
2) Обеспечить кроссплатформенность основной IDE (vs)
3) Собрать компактный FCL (без лишних никому не нужных каркасов)
4) Увеличить производительность исполнения кода, производительность vm
5) сделать базовые фичи CLR more configurable — управление gc, памятью. GC сейчас вообще работает еле как.
6) создать таки понятный интерфейс interapobility для взаимодействия с native C/C++
Самому языку нужны синтаксически и семантически простые и выразительные средства для разработки ПО в OOP парадигме без заиграваний с ФП.
Здравствуйте, a_g_99, Вы писали:
__>3) Собрать компактный FCL (без лишних никому не нужных каркасов)
.NET FW Core Profile?
__>4) Увеличить производительность исполнения кода, производительность vm
На правах моих фантазий — в сравнительно недалеком будущем должен выйти СТР с новым CLR
__>Самому языку нужны синтаксически и семантически простые и выразительные средства для разработки ПО в OOP парадигме без заиграваний с ФП.
Ну так в том и вопрос — какие?
... << RSDN@Home 1.2.0 alpha 5 rev. 23 on Windows 8 6.2.9200.0>>
0) Пусть расхардкодят реализацию того что под капотом у async/await. Сейчас у async зашито порождение Task из AsyncTaskMethodBuilder и приехали. В идеале — пусть доведут её до уровня linq, который можно натянуть на что угодно, лишь бы методы были. Если не сдюжат придумать выразительных средств чтоб дать ту же свободу, какую дал linq, пусть хотя бы подхватывают async MyTask<RetType> func() где MyTask : Task (или IAwaitable, или что-то имеющее метод GetAwaiter), а MyAsyncMethodBuilder которым билдить прописан у MyTask в каком-нить аттрибуте. Очень надо даже для простых сценариев
1) await lock(IAsyncLockable){ } — и пачку примитовов для синхронизации async/await методов, желательно реализованных на интерфейсе IAsyncLockable, чтоб можно было всякие свои реализации локов писать.
2) паттерн-матчинг, АТД
3) traits/mixins — чтоб можно было описать интерфейс, реализацию, и подключать к классу нужный функционал без наследования
public mixin A
{
//функция будет вставлена как приватная в классы использующие mixinprivate mixin void Func()
{
}
private mixin x;//x будет доступен в классах использующих mixin как обычная переменная
//функция видна только внутри Aprivate void Func2()
{
}
private int x2;//переменная x2 доступнка только внутри A, в наследниках A она не видна (заманглить до <MixinField>_k_x2;
}
public mixin B
{
private mixin x;
public mixin Func3();
}
public class С : A,B//так как поле x в A и B объявлено как mixin и тип совпадает, это компилируется, и поле x одно в классе C, расшаренное между методами его использующими
{
private new void Func()//делаем свою реализацию A.Func
{
}
}
4) infoof/memberof — любой способ сгодится, лишь бы не строки как сейчас, которые умирают при малейшем рефакторинге.
5) Реквестую чуда! memberof(Func).ToExpression() — и чтоб у меня целый метод получился в виде Expression Tree, а в нём вызовы вложенных методов по мере надобности чтоб тоже поддерживали .ToExpression(), может и без roslyn'а можно будет жару задать
6) Фиктивный интерфейс INumeric в котором описаны математические операторы Add,Sub,Neg..., либо NumericAttribute, чтоб можно было на дженериках реализовывать математические алгоритмы и пользоваться операторами для +-*/ и т.п.. Ну и для классов у которых объявлена поддержка этого Numeric вызывать соответствующие статические операторы либо методы самого класса.
7) where T : new() уже есть, пусть слепят наконец where T : new(int,bool,string) т.е. возможность вызывать конструктор с параметрами
8) Если 7 получится, пригодятся ещё и еxtension ctor'ы, чтоб можно было подсунуть компилятору свою реализацию конструктора.
9) локальные функции, если совсем не получится, хотя-бы var для вывода типов у лямбд пусть допилят, качественный, с поддержкой рекурсивных вызовов.
10) Приватные поля у свойств. В сочетании с локальными функциями вообще было бы здорово, но и без них можно было бы жить лучше:
//чисто для примераpublic int X
{
static volatile bool b;
int x;
get { if(b) return x; else throw new NotInitalizedException(); }
set { x = value; b = true; }
}
11) нормальную поддержку туплов, а лучше даже пусть доведут поддержку анонимных типов до
//чтоб из функции возвращался анонимный тип public (int a, bool b, string s) func()
{
return new {1,true,""};
}
//котрый потом можно было бы легко разложить в var (x,y,z) = func(); //и далее можно использовать x,y,z
//илиvar t = func(); //а если так, то можно использовать t.a, t.b, t.s и втопку эти кривые t.ItemXXX
И структурную эквивалентность, пусть CLR им обеспечит при условии полного совпадения типов, имён и порядка. В крайнем случае пусть эти анонимные типы будут наследниками от Tuple<> подходящего размера.
12) Оператор .?
13) Типизация dynamic'ов
//интерфейс фиктивный, его не обязан поддерживать ни один класс, нужен только для описания того что может dynamic к которому его применяютinterface IDyn
{
void SetX(int a);
bool GetY();
}
interface IRes
{
int Length { get; }
}
dynamic<IRes> func(dynamic<IDyn> a)
{
a.| //тут автокомплит подсказывает что у a есть SetX() и GetY()
a.Prop = 5; //тут не скомпилируется, так как у интерфейса IDyn не описано свойство Propreturn new int[10];//компилируется, так как int[] имеет свойство Length
}
При этом если вызывают func(A) и A не имеет методов описанных в IDyn, то ошибка компиляции. A не обязан быть наследником от IDyn, главное чтоб все описанные в нём методы/свойства/поля были.
14) Ещё одна типизация dynamic'ов, доводящая их почти до квази-цитат:
dynamic func(dynamic a)
{
}
string funcInt(int a) = func; //пусть компилятор сам подставит типы и скомпилирует функцию,
//причём такую же быструю как обычную
//либо даст ошибку компиляции в той строке где func не может корректно скомпилироваться с аргументом a типа int и возвращаемым значением типа string.
15) Пусть lock поддерживает не только Monitor.Enter/Monitor.Exit но и классы поддерживающие ILockable интерфейс, который вписать во всякие эти SpinLock, Semaphore/SemaphoreSlim, ReaderWriterLock и т.п.
16) приватные extension методы
17) Пусть в аттрибуты можно будет вписать лямбду и потом вызвать её, а лучше даже ещё и получить как Expression Tree
18) Возможность вернуть наследника из конструктора, в сочетании с 7 может решить кучу проблем. Можно ограничиться только абстрактными классами, можно вообще всем разрешить объявлять такие конструкторы:
public abstract A
{
public new this A()//или какой-нить другой набор слов по вкусу
{
return new B();//прощайте фабричные методы
}
private B : A
{
}
}
//использование
A a = new A();//в реальности в a попадёт экземпляр B
19) Именованные индексаторы, типа string Name[int x, int y] { get { ... } set { ... } }, бывает нужно раз в год, и тут же вспоминаешь что по этой фиче паритет с VB нарушен.
Бонусом киллер-фича для IDE: пусть положат все серо-серые иконки используемые студией отдельно, чтоб их можно было заменить на цветные без патчинга её бинарей!
Здравствуйте, AndrewVK, Вы писали:
AVK>.NET FW Core Profile?
Я не знаю что это, если объясните будет круто.
AVK>На правах моих фантазий — в сравнительно недалеком будущем должен выйти СТР с новым CLR
Будет круто. Это же только фантазия ?
AVK>Ну так в том и вопрос — какие?
Я буду кусочками писать в несколько постов, потому как большие посты у меня почему-то слетают.
Начиная с самого простого:
1) Tuples
Уже писали, я кратко.
Пример:
{A, B, C} f(){
return {a,b,c};
}
Это будет мощной фичей для языка типа C#, хотя реализовать это будет не очень просто
2) Postfix expressions (в дополнение к обычному)
Пример:
a++ if (a>2);
a-- while (a>100);
3) each for tuples/arrays/iterators. тут возможны различные варианты реализации
4) repeat/retry operators для циклов.
repeat — повторить цикл сначала, retry — повторить итерацию заново
пример:
while(object.Read()){
bool isDel = false;
{ object.remove(); isDel=!0; } if (object.id==1);
repeat if (isDel);
}
_>12) Оператор .?
В оффлайне подсказали что просто .? может быть не очень удобным, если вместо значения default(T) нужно получить что-то другое, например int.MinValue;
Лучше его форма c else в виде ':' по аналогии с тернарным оператором:
var x = A.?B.?C : int.MinValue;
: можно сделать опцинальным, если его нет, а до C не добрались x = default(T)
__>Скорее не про c# а про платформу в целом: __>1) Обеспечить реальную кроссплатформенность платформы (без всяких поделок) __>2) Обеспечить кроссплатформенность основной IDE (vs) __>3) Собрать компактный FCL (без лишних никому не нужных каркасов) __>4) Увеличить производительность исполнения кода, производительность vm __>5) сделать базовые фичи CLR more configurable — управление gc, памятью. GC сейчас вообще работает еле как. __>6) создать таки понятный интерфейс interapobility для взаимодействия с native C/C++
Почти все, что я хотел уже высказали более компетентные коллеги. Только одного не нашел — always is expression.
Безумно удобная фича, причем даже не могу сходу найти пример, где она сломает обратную совместимость.
Нужен возврат последнего значения из блока (и в switch из case). Если значение не используется, то работает как раньше.
var x = if (cond) { 1 } else { 2 } // пример использованияvar x = if (cond) { 1 } else { "x" } // ошибка вывода типаif (cond) { GetIntValue(); } else { GetStringValue(); } // старый код - все ок, значение не используется
if без else и foreach не возвращают значения (возвращают void).
Здравствуйте, TimurSPB, Вы писали:
TSP>А не проще тогда сразу на плюсах писать?
Иногда проще, иногда нет. c# сложно сравнивать с с++ так он имеет другую базовую архитектуру и немного другое назначение. То о чем я писал, это не какая-то недостижимая мечта, а вполне осуществимая техническая задача.
По пунктам:
_>1) Обеспечить реальную кроссплатформенность платформы (без всяких поделок)
Она уже фактически существует в виде thrid-party libs like Mono, Monotouch, Monodroid. MS и делать особо ничего не нужно, просто купить команду и доработать их проекты в соответствии с общей идеологией.
_>2) Обеспечить кроссплатформенность основной IDE (vs)
В принципе не вижу проблем. Они портировали на MacOs Office, выглядит очень достойно.
_>3) Собрать компактный FCL (без лишних никому не нужных каркасов)
Это не вопрос большой сложности. Это вопрос правильной архитектуры при разработки платформы. Во время выпуска версии 3.5 было допущено много очень серьезных ошибок и промахов с добавлением "новых фрэймворков". Исправить это при наличии мозгов и политической воли — задача вполне обычная.
_>4) Увеличить производительность исполнения кода, производительность vm _>5) сделать базовые фичи CLR more configurable — управление gc, памятью. GC сейчас вообще работает еле как.
Опять же не невозможно. Это вопрос ресурсов. Вместо пары тысяч бангладешцев, пакистанцев, мумбайских индусов нужно нанять десяток датчан или японцев, которые имеют определенные навыки. Пусть переманят у Google или Oracle.
_>6) создать таки понятный интерфейс interapobility для взаимодействия с native C/C++
Ну это по умолчанию. Важная фича, а фактически плохо реализована, хотя все пути известны.
Мне от C# ничего не надо.
А вот несколько мелких фичей в CLR мне бы очень помогли.
1)Функциональный тип.
Реализация:
value тип с двумя указателями.
Первый this второй реальный адрес функции.
Грузим this в ECX и передаем управление на адрес. Параметры как обычно.
В случае со статическими функциями, если мне не изменяет склероз, ECX может быть изменен функцией как угодно.
При создании этого объекта для виртуального метода или интерфейса в таблицу виртуальных функций лезем при создании объекта.
Таким образом, будет очень простой и дешёвый вызов функции.
2)Структурная эквивалентность типов.
Реализуется на раз. Просто при загрузке типа проверяем наличие атрибута и тупо сравниваем типы на эквивалентность.
3)Пусть, наконец, реализуют хвостовую рекурсию. То, что есть сейчас это не реализация, а отмазка. Ибо тормозит. Хотя хвостовые вызовы должны работать быстрее обычных. Ибо там возни меньше нужно.
4)Пусть сделают void полноценным типом. Те чтобы им можно было параметризовать генерики. Создавать переменные типа void. Создавать массив типа void. Итп.
Это сразу убьёт кучу копипасты которая происходит только из-за того что void нужно обрабатывать отдельно.
Если это сделают можно будет делать языки под .НЕТ не сильно матерясь.
А сейчас это просто порнография получается. Приходится генерировать классы тоннами, чтобы результирующий код не тормозил. Но из-за того что загрузка самих классов в .НЕТ тормозит (как они это сделали не понимаю) замедляется старт приложения.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>3)Пусть, наконец, реализуют хвостовую рекурсию. То, что есть сейчас это не реализация, а отмазка. Ибо тормозит. Хотя хвостовые вызовы должны работать быстрее обычных. Ибо там возни меньше нужно.
Если сделать по умолчанию, сall stack при дебаге будет иногда теряться. Но если бы добавили управление аттрибутом (какой-нить [TailCallOptimize] на метод) — часто спасало бы от кучи геморроя (для алгоритмов, которые естественнее записываются через рекурсию).
WH>4)Пусть сделают void полноценным типом. Те чтобы им можно было параметризовать генерики. Создавать переменные типа void. Создавать массив типа void. Итп. WH>Это сразу убьёт кучу копипасты которая происходит только из-за того что void нужно обрабатывать отдельно.
+1024
Здравствуйте, Ziaw, Вы писали:
Z>Почти все, что я хотел уже высказали более компетентные коллеги. Только одного не нашел — always is expression.
100% не сделают.
Z>Безумно удобная фича, причем даже не могу сходу найти пример, где она сломает обратную совместимость.
Весь дизайн шарпа настроен на стэйтменты. Главная проблема — шарп глотает возвращаемые значения в StatmentExpression, так что у людей будет куча ошибок на ровном месте. Изменение этого дела приведет к обратной несовместимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, artelk, Вы писали:
A>Если сделать по умолчанию, сall stack при дебаге будет иногда теряться. Но если бы добавили управление аттрибутом (какой-нить [TailCallOptimize] на метод) — часто спасало бы от кучи геморроя (для алгоритмов, которые естественнее записываются через рекурсию).
У них уже есть такое http://msdn.microsoft.com/ru-ru/library/system.reflection.emit.opcodes.tailcall.aspx
Причем на моно оно работает быстро. А в реализации майкософт тормозит.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>100% не сделают.
VD>Весь дизайн шарпа настроен на стэйтменты. Главная проблема — шарп глотает возвращаемые значения в StatmentExpression, так что у людей будет куча ошибок на ровном месте. Изменение этого дела приведет к обратной несовместимости.
Можно же сделать предупреждение, которое включается флагом компилятора. Это не проблема.
