Я так понимаю, ты с какой-то целью запостил этот вопрос в два форума. Если в форуме по .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, так что у людей будет куча ошибок на ровном месте. Изменение этого дела приведет к обратной несовместимости.
Можно же сделать предупреждение, которое включается флагом компилятора. Это не проблема.
Z>Можно же сделать предупреждение, которое включается флагом компилятора. Это не проблема.
тогда уж делать атрибутом, который можно навесить на метод, класс, assembly. Если делать флагом, то не получится одновременно использовать и старый, и новый код.
Здравствуйте, DarkGray, Вы писали:
_>> .? может быть не очень удобным, если вместо значения default(T) нужно получить что-то другое, например int.MinValue;
DG>default(T) в operator .? — это всегда null (за исключением вырожденного случая для void)
DG>и соответственно, это выражение
_>> var x = A.?B.?C : int.MinValue;
DG>можно сделать через имеющийся operator ?? DG>
DG>var x = A.?B.?C ?? int.MinValue;
DG>
то есть ты хочешь, чтобы A.?B.?C вернуло Nullable<int> ??? Оно конечно понятно и логично, но что делать если С — ссылочный тип(object, например) ??
возвращать Nullable<C> если С struct и просто С, если С — ссылочный — это костыль, ИМХО. Нужен нормальный Maybe, работающий и для struct и для class. Но наличие одновременно и Nullable и Maybe — это тоже так себе решение...
Здравствуйте, Ziaw, Вы писали:
Z>Основная причина, это слишком большой шаг, его страшно делать.
На самом деле нет, почитайте Липперта. У него половина блога — как раз о вопросах "почему нет фичи X" и "по каким правилам мы добавляем новые возможности".
Почти всё, что добавлялось в шарп было:
1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом).
2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Не, есть конечно отдельные некрасивые моменты типа 100500 способов для объявления массива и пары delegate {} / () =>, но на практике они не мешают.
Напротив, чуть ли не половина фич в этой и параллельной ветке (в дотнетовском форуме) выглядит как-то так:
— запросы типа "я привык к XXX, тут всё не так, сделайте как там".
— фичи, которые будут неудобны на практике и про которые 1000развсё обжёвано.
— и шедевральные "тут прикольная фича есть, делать 5 минут, надо только немного поломать синтаксис/рантайм и выкинуть нафиг старый код чтобы под lin работало".
Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"?
Если уж предлагать — начинайте с реальных сценариев использования.
The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.)
Вот такое:
var x = ReadLine();
var y = "456";
var z = x ?? { y = "123"; Save(y); y;};
Console.WriteLine(y);
Это типа удобная фича?
Со всем прочим — то же самое. Тот же infoof, если его добавят, превратится в "а теперь то же самое, только для expression-ов, иначе неудобно указывать перегрузку.". Фишки из XXX будут конфликтовать с YYY. Always as expression породит тонну холиваров — писать ли return в методах вида
static int GetValueA() { GetValueB(); }
, что круче — ?: или if/else, почему нельзя сделать x = foreach(...) {} ?? 123 и т.д. и т.п.
Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Здравствуйте, Sinix, Вы писали:
S>На самом деле нет, почитайте Липперта. У него половина блога — как раз о вопросах "почему нет фичи X" и "по каким правилам мы добавляем новые возможности".
Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени.
S>Почти всё, что добавлялось в шарп было: S>1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом). S>2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок?
S>Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"?
Вы сейчас точно ко мне обращаетесь? У кого и что сломается?
S>Если уж предлагать — начинайте с реальных сценариев использования.
Я думаю тут неглупые люди, которые не раз создавали не инициализированные переменные перед блоками using и try, к примеру. Часто эти блоки являются expression именно для инициализации именно этой переменной. Часто переменная остается не инициализированной по ошибке программиста.
S>конкретно про statement as expression: S>
S>The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
S>The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.)
Ну это религия. Я раньше был ярым поклонником этой точки зрения, но потом, как-то отошел от догм. Просто сейчас пишу на разных языках, на C# и JS ощутимо недостает этой фичи, в отличии от Ruby&CoffeeScript.
S>Вот такое: S>
S>var x = ReadLine();
S>var y = "456";
S>var z = x ?? { y = "123"; Save(y); y;};
S>Console.WriteLine(y);
S>
S>Это типа удобная фича?
Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод?
S>Со всем прочим — то же самое. Тот же infoof, если его добавят, превратится в "а теперь то же самое, только для expression-ов, иначе неудобно указывать перегрузку.". Фишки из XXX будут конфликтовать с YYY. Always as expression породит тонну холиваров — писать ли return в методах вида S>
S>static int GetValueA() { GetValueB(); }
S>
, что круче — ?: или if/else, почему нельзя сделать x = foreach(...) {} ?? 123 и т.д. и т.п.
Покажите мне хоть одну фичу из введенных в язык, по которой не было холивара на RSDN.
S>Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Это не эксперимент. Эта фича давно обкатана во множестве императивных языков. Ну и надо определиться, чего хочется, совершенно новых вещей или тех, что есть в других языках. А то я вижу претензии по обоим пунктам одновременно.
Здравствуйте, Ziaw, Вы писали:
Z>Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени.
Я подписан на блоги (старый, новый), на SO за Липпертом не слежу.
Z>Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок?
Не вопрос. Для какой фичи только? Их тут с пару десятков уже предложили. Если речь про "statement as expression" — чем плохи отдельные методы?
S>>Не, ну блииин, ребят, у себя вы так же к пользователям относитесь — "мне удобно, если у кого что поломается — их проблемы"? Z>Вы сейчас точно ко мне обращаетесь? У кого и что сломается?
Навкидку:
public void Foo(Action<int> a)
{
}
public void Foo(Func<int, string> b)
{
}
public void Bar()
{
Foo(delegate(int y)
{
Console.ReadLine(); // Какую перегрузку вызывать после добавления statement as expression?
});
Foo(delegate(int y)
{
return Console.ReadLine();
});
// Если не устраивает пример выше:
Foo(y => { Console.ReadLine(); }); // Тот же вопрос.
Foo(y => Console.ReadLine());
}
Если не хватает — можно ещё покопаться в property/collection initializers и в синтаксисе анонимных типов, там тоже могут возникнуть очень интересные неоднозначности.
Z>Я думаю тут неглупые люди, которые не раз создавали не инициализированные переменные перед блоками using и try, к примеру. Часто эти блоки являются expression именно для инициализации именно этой переменной. Часто переменная остается не инициализированной по ошибке программиста.
Останется не инициализированной — компилятор предупредит.
Проблема в том, что не менее часто блоки являются местом для добавления побочных эффектов — всё остальное спокойно реализуется через выражения.
Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как
int y;
var x = SomeLogicC() &&
try
{
SomeLogicA() & SomeLogicB();
}
catch(SomeException ex)
{
Log(ex);
y = 42;
false;
}
В общем, нечего тянуть ФП-привычки в грязный императивный мир
The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects.
Z>Ну это религия. Я раньше был ярым поклонником этой точки зрения, но потом, как-то отошел от догм. Просто сейчас пишу на разных языках, на C# и JS ощутимо недостает этой фичи, в отличии от Ruby&CoffeeScript.
Если гипотеза поддаётся проверке научными методами, то на религию это непохоже. Отсутствие побочных эффектов сильно упрощает код: меньше зависимостей, проще проверка корректности кода (вплоть до статической верификации через CodeContracts), проще растаскивать код на асинхронные вызовы и т.д. и т.п.
Да, в скриптовых языках возможность дописать чуть-чуть лапшекода ради экономии пары строк кода может быть очень удобной. Но в насквозь мейнстримном и приземлённом шарпе добавление сайд-эффектов в выражения приведёт только к одной реакции — "липперт разрешил"(с)
S>>Это типа удобная фича? Z>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод?
Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред:
if ({
await ALotOfCode1();
x == y;
})
{
ALotOfCode2();
}
— ужасен.
S>>Для экспериментов есть тонна других языков, зачем всё стаскивать в один?
Z>Это не эксперимент. Эта фича давно обкатана во множестве императивных языков.
Вот пусть она там и остаётся
Здравствуйте, Sinix, Вы писали: S>Здравствуйте, Ziaw, Вы писали: Z>>Липперта надо читать везде или только на stackowerflow? Я раньше читал его, но бросил, когда перестал делать ставку на один язык. Не могу сейчас уделять ему столько времени. S>Я подписан на блоги (старый, новый), на SO за Липпертом не слежу.
Так зачем предлагаете читать его блоги, если ответ на мой вопрос находится на SO? Z>>Предлагаю привести опровергающие примеры для предлагаемой фичи. Примеры, вроде "вот тут можно сделать как автосвойство, так и оставить обычное" не берем в рассчет, ок? S>Не вопрос. Для какой фичи только? Их тут с пару десятков уже предложили. Если речь про "statement as expression" — чем плохи отдельные методы?
Наша с вами беседа касается одной единственной фичи, я больше ничего не предлагал. Не надо так активно резать контекст. Я просил противоречий с: S>Почти всё, что добавлялось в шарп было: S>1. Полезным для определённых сценариев (даже именованные параметры вполне полезны, особенно для интеропа с вордом). S>2. Не дублировало имеющийся функционал, а дополняло его (автосвойства не отменили обычных свойств etc).
Навкидку:
S>
S> public void Foo(Action<int> a)
S> {
S> }
S> public void Foo(Func<int, string> b)
S> {
S> }
S> public void Bar()
S> {
S> Foo(delegate(int y)
S> {
S> Console.ReadLine(); // Какую перегрузку вызывать после добавления statement as expression?
S> });
S> Foo(delegate(int y)
S> {
S> return Console.ReadLine();
S> });
S> // Если не устраивает пример выше:
S> Foo(y => { Console.ReadLine(); }); // Тот же вопрос.
S> Foo(y => Console.ReadLine());
S> }
S>
S>Если не хватает — можно ещё покопаться в property/collection initializers и в синтаксисе анонимных типов, там тоже могут возникнуть очень интересные неоднозначности.
Это все решаемо. В данном случае можно предложить обязать использовать return как способ возврата значений из функции. Под это можно даже что-то религиозное подвести. S>Останется не инициализированной — компилятор предупредит.
Ну это же костыль, призванный компенсировать отсутствие данной фичи. Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения. S>Проблема в том, что не менее часто блоки являются местом для добавления побочных эффектов — всё остальное спокойно реализуется через выражения.
Более того, методы являются местом для добавления побочных эффектов еще чаще. Что совершенно не мешает использовать их вызов в выражениях. S>Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как S>
Типовой говнокод. Он и сейчас выглядит не лучше. S>В общем, нечего тянуть ФП-привычки в грязный императивный мир
При чем тут, кстати, ФП? S>Да, в скриптовых языках возможность дописать чуть-чуть лапшекода ради экономии пары строк кода может быть очень удобной. Но в насквозь мейнстримном и приземлённом шарпе добавление сайд-эффектов в выражения приведёт только к одной реакции — "липперт разрешил"(с)
Что такое скриптовые языки? Чем лапшекод в них отличается от лапшекода в C#? Z>>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод? S>Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред:
Еще раз: покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод. Z>>Это не эксперимент. Эта фича давно обкатана во множестве императивных языков. S>Вот пусть она там и остаётся
Слишком расползается ветка, давай про говнокод который можно создать отделим:
S>Если разрешить использовать стейтменты в выражениях, мы убьём это различие и типовой код будет выглядеть как
Сейчас ведь так не выглядит? Все возможности есть.
int y;
var x = SomeLogicC() &&
Statements.TryCatch(() =>
{
return SomeLogicA() & SomeLogicB();
}, (ex) =>
{
Log(ex);
y = 42;
return false;
})
Здравствуйте, Ziaw, Вы писали:
Z>Так зачем предлагаете читать его блоги, если ответ на мой вопрос находится на SO?
Потому что на SO рассмотрен конкретный, частный случай. Общие правила, по которым та или иная фича попадает в язык рассмотрены чуть ли не в каждой статье из блога. Классика — "because no one ever designed, specified, implemented, tested, documented and shipped that feature."
Блог Липперта ценен именно подробным рассмотрением последствий того или иного решения. В отличие от большинства ура-постов "что там думать — добавить и будет красиво", Липперт не ленится расписать все (зачастую весьма неочевидные) подводные камни и то, как они влияют на дизайн языка. На мой взгляд, такой сверхответственный подход к разработке — очень полезный навык. Лично мне чтение Липперта и не менее замечательной Framework Design Guidelines дало намного больше чем считающийся абсолютной классикой "Code Complete" МакКоннела.
Z>Наша с вами беседа касается одной единственной фичи, я больше ничего не предлагал. Не надо так активно резать контекст. Я просил противоречий с:
[пример противоречий скипнут] Z>Это все решаемо. В данном случае можно предложить обязать использовать return как способ возврата значений из функции. Под это можно даже что-то религиозное подвести.
Собственно в этом и заключается разница между теорией и практикой. На практике у нас появляются отдельные виды блоков — expression statement и return statement, довольно серьёзно меняется синтаксис, спецификация и, соответственно, реализация компилятора. Стоимость "одной маленькой фишки" становится сопоставимой с добавлением big thing уровня linq. При этом фишка останется чужеродной для всех, кто хотя бы год работал с шарпом, т.к. идёт в разрез с привычной идеологией "выражения — без побочных эффектов, стейтменты — для побочных эффектов".
Ещё один пример: Z>Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения.
Сравните
int x;
using (var y = new SomeResource())
{
x = y.Z;
}
// vsvar x = using (var y = new SomeResource()) { y.Z };
Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
И ещё: Z>>>Покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод? S>>Остальные фичи сдизайнены так, что накосячить сложнее, а к возможному говнокоду добавлен очевидный выигрыш. Тут, на мой взгляд, выгода очень неочевидна, вред: Z>Еще раз: покажите мне хоть одну фичу из уже введенных в язык, с которой я не смогу создать подобный говнокод.
Пардон, но это уже сказка про белого бычка. Плиз, прочитайте всё что написано выше. Поймите, я не собираюсь доказывать, что фича XXX бесполезна. Моя позиция — её добавление создаст больше проблем, чем решает. Свои доводы я привёл, теперь ваша очередь
Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Здравствуйте, Sinix, Вы писали:
S>Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
Вот такой. Постоянно так пишу.
def x = using (y = new SomeResource())
{
y.Z
}
S>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Например, код выше.
Обе переменные неизменяемые. y виден только внутри using.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Вот такой. Постоянно так пишу.
def x = using (y = new SomeResource())
{
y.Z
}
Так это ж N, в нём этот код выглядит естественно и удобно — большинство переменных immutable и чтобы добавить странные побочные эффекты надо сильно постараться.
S>>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы WH>Например, код выше.
Если честно — спорно. Аналог в шарпе не сильно страшнее:
int x;
using (var y = new SomeResource())
{
x = y.Z;
}
Плюс, его не надо переписывать если нужно добавить побочные эффекты, если x надо инициалиизировать только в отдельных ветках разветвлённого if, или если надо заполнить несколько переменных.
Повторюсь, такие вещи надо с самого начала закладывать в язык, без кортежей и immutable by default подобное дополнение будет очень непрактичным.
Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
Здравствуйте, Sinix, Вы писали: S>Блог Липперта ценен именно подробным рассмотрением последствий того или иного решения. В отличие от большинства ура-постов "что там думать — добавить и будет красиво", Липперт не ленится расписать все (зачастую весьма неочевидные) подводные камни и то, как они влияют на дизайн языка. На мой взгляд, такой сверхответственный подход к разработке — очень полезный навык. Лично мне чтение Липперта и не менее замечательной Framework Design Guidelines дало намного больше чем считающийся абсолютной классикой "Code Complete" МакКоннела.
Где вы нашли ура пост? Я предложил фичу на обсуждение, аргументы против пока слабенькие. S>Собственно в этом и заключается разница между теорией и практикой. На практике у нас появляются отдельные виды блоков — expression statement и return statement, довольно серьёзно меняется синтаксис, спецификация и, соответственно, реализация компилятора. Стоимость "одной маленькой фишки" становится сопоставимой с добавлением big thing уровня linq. При этом фишка останется чужеродной для всех, кто хотя бы год работал с шарпом, т.к. идёт в разрез с привычной идеологией "выражения — без побочных эффектов, стейтменты — для побочных эффектов".
Появляется два вида блоков — тело функции и блок-выражение. Они и сейчас семантически различаются.
Ещё один пример:
Z>>Мне недостаточно средств языка, чтобы показать, что этот using мне нужен для вычисления одного конкретного значения. S>Сравните S>
S>int x;
S>using (var y = new SomeResource())
S>{
S> x = y.Z;
S>}
S>// vs
S>var x = using (var y = new SomeResource()) { y.Z };
S>
S>Вот честно, какой вариант кода вам больше понравится поддерживать? И то же самое — если "вычисление одного конкретного значения" займёт несколько строк с несколькими if
Ок, отвечу, а вы честно скажите: почему вы один вариант отформатировали, а второй слепили в кучу? Честно, мне второй симпатичнее, в общем случае, глядя внутрь первого блока я не понимаю, откуда взялась x, какого она типа, и для чего она понадобится дальше в блоке (или не понадобится). Меня всегда напрягают места, где значение ассайнится в какую-то непонятную переменную, надо искать что с ней будет дальше и где ее еще изменяют, а иногда еще и думать, что там было до этого и не потерялось ли оно по ошибке. Естественно я про реальный подобный код, а не трехбуквенный прототип. S>Пардон, но это уже сказка про белого бычка. Плиз, прочитайте всё что написано выше. Поймите, я не собираюсь доказывать, что фича XXX бесполезна. Моя позиция — её добавление создаст больше проблем, чем решает. Свои доводы я привёл, теперь ваша очередь
Естественно, потому, что посылка про то, что с этой фичей можно налабать много говнокода не выдерживает критики. А вы уже два раза избегаете ответа на прямой вопрос. Все описанные вами примеры говнокода можно воспроизвести без выражений. И все введенные с первой версии фичи позволяют наколобасить все более непонятный код, это неизбежная плата за возможности. Вы забыли аскетичность первой версии, если бы тогда нам показали сразу все фичи, которые появились сейчас, мы бы их все до одной отвергли как ненужное (за небольшим исключением, вроде generics). S>Для начала — покажите хоть один сценарий, который окупит все вышеперечисленные проблемы — как в реализации, так и в использовании. Только плиз, не надо отвечать "нет никаких проблем". Вот это как раз религия и неконструктивно
Я не говорю, что проблем нет, я прошу их показать. Одну проблему вы действительно показали (вывод типа функции), я предложил решение. А про побочное действие, это действительно религия, оно и сейчас в C# никак средствами языка не регулируется.
А окупит себя подход к дизайну кода, формирующий более внятные потоки данных в методе. После небольшого опыта написания кода на языке с иммутальными переменными, во всех языках стараюсь обходиться минимумом мутабельных. Код чище и понятнее выходит. Наверняка и вы это делаете, хотя бы на уровне полей класса, ведь других ограничений мутабельности шарп не дает. Так вот, без обсуждаемой фичи, количество локальных мутабельных переменных сократить до минимума не удается, хотя они нужны просто для перетаскивания значения из одной точки кода в другую и никаких изменений с ними по дороге не происходит.
Похоже на религию, я согласен, это сложно объяснить на пальцах, надо просто поприменять немного. Уфф. Чувствую себя человеком пытающемся объяснить пользу var тому, кто им плотно не пользовался.
Здравствуйте, Sinix, Вы писали:
S>Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
А ты погляди внимательно на все предложения в этих двух темах (тут и в дотнете). Почти все предложения и хотят фичей из немерла. Только многие боятся в этом признаться (даже сами себе), так как после этого придется отвечать на вопрос — "А почему просто не взять тот самый Немерл?".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
VD>А ты погляди внимательно на все предложения в этих двух темах (тут и в дотнете). Почти все предложения и хотят фичей из немерла. Только многие боятся в этом признаться (даже сами себе), так как после этого придется отвечать на вопрос — "А почему просто не взять тот самый Немерл?".
Здравствуйте, Ziaw, Вы писали:
Z>Где вы нашли ура пост?
Ок, будем политкорректны. Пост с альтернативным взглядом на стоимость добавления новой фичи. Пойдёт?
Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов.
На этом предлагаю закругляться — у меня аргументы закончились, еси продолжать, будем только по кругу ходить.
Здравствуйте, hi_octane, Вы писали:
_>А на чём сейчас программируют самые крутые программисты?
Этого я не знаю . Спросите крутых программистов
_>Вот ты, например, на чём?
Сейчас javascript, c#, python, немного С и PL/SQL.
Также смотрю в сторону java и ruby, как на платформы которые возможно буду использовать в будущем. Нравится erlang, но этот интерес скорее академический; абсолютно уверен, что не буду использовать его в качестве языка программирования/платформы в реальных проектах.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Если добавить — мы получим уже не шарп, а урезанный диалект немерла, со своим стилем кодирования и дизайна API. Ну и зачем?
VD>А ты погляди внимательно на все предложения в этих двух темах (тут и в дотнете). Почти все предложения и хотят фичей из немерла.
Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было
Здравствуйте, Ziaw, Вы писали:
Z>Я не говорю, что проблем нет, я прошу их показать. Одну проблему вы действительно показали (вывод типа функции), я предложил решение. А про побочное действие, это действительно религия, оно и сейчас в C# никак средствами языка не регулируется.
Слишком часто программы работают исключительно из за побочных эффектов, про которые программист был реально не в курсе. Это особенность императивного программирования. C# императивный до мозга костей, функциональные феньки на самом деле "как бы функциональные", а реально тот же императив завернутый в синтаксис. Посмотри количество вопросов про лямбды на SO, блочные итераторы, помножь на всю массу С# разработчиков и станет понятно, почему ты предлагаешь слишком радикальное изменение.
Есть такой консервативный язык, называется Java. В нем функциональщина отсутствует как явление. При этом почему то серверный энтерпрайз чуть не целиком пишется на Java. Очень сложно найти более императивного программиста, нежели джавист. И вот как то странно, императивная Джава проникает на платформы с бОльшей легкостью, а та же функциональная Scala так и используется кое где.
Здравствуйте, Tanker, Вы писали:
Z>>Я не говорю, что проблем нет, я прошу их показать. Одну проблему вы действительно показали (вывод типа функции), я предложил решение. А про побочное действие, это действительно религия, оно и сейчас в C# никак средствами языка не регулируется.
T>Слишком часто программы работают исключительно из за побочных эффектов, про которые программист был реально не в курсе. Это особенность императивного программирования. C# императивный до мозга костей, функциональные феньки на самом деле "как бы функциональные", а реально тот же императив завернутый в синтаксис. Посмотри количество вопросов про лямбды на SO, блочные итераторы, помножь на всю массу С# разработчиков и станет понятно, почему ты предлагаешь слишком радикальное изменение.
Что я предложил функционального? Радикальное — да, функциональное каким боком? И не надо мне доказывать императивность C#, это, как бы, хорошо известный факт.
T>Есть такой консервативный язык, называется Java. В нем функциональщина отсутствует как явление. При этом почему то серверный энтерпрайз чуть не целиком пишется на Java. Очень сложно найти более императивного программиста, нежели джавист. И вот как то странно, императивная Джава проникает на платформы с бОльшей легкостью, а та же функциональная Scala так и используется кое где.
Есть еще COBOL. В ентерпрайзы проникал как нож в масло. Где он сейчас? Лямбды в java вводят, наверное, для того, чтобы нишу энтерпрайза уступить. Scala довольно радикальна и молода, чтобы делать по ней какие-то выводы. C# постарше, но заметно моложе явы и не вызывает доверия на юниксах, а это серьезный недостаток.
По факту, и императив и функциональщина прочно вошли уже почти во все распространенные языки. Метапрограммирование тоже развивается, в частности в C#. Сплав из эти трех материалов и будет определять направление развития всех популярных языков на ближайшее будущее. Тут никуда ведь не деться, революций ожидать особо неоткуда, вектор стабильный. И, да, пользуясь случаем, хочу поблагодарить MS за лямбды, это дало хороший пинок неповоротливым Java&C++.
Здравствуйте, Tanker, Вы писали:
T>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было
Фичи из немерла == фичи, которые существуют в немерле.
Фичи из немерла != фичи, которые были немерл подарил миру.
Здравствуйте, Ziaw, Вы писали:
Z>Что я предложил функционального? Радикальное — да, функциональное каким боком? И не надо мне доказывать императивность C#, это, как бы, хорошо известный факт.
Z>Есть еще COBOL. В ентерпрайзы проникал как нож в масло. Где он сейчас? Лямбды в java вводят, наверное, для того, чтобы нишу энтерпрайза уступить. Scala довольно радикальна и молода, чтобы делать по ней какие-то выводы. C# постарше, но заметно моложе явы и не вызывает доверия на юниксах, а это серьезный недостаток.
Лямбды в джаву уже лет пять минимум вводят. C#
Z>По факту, и императив и функциональщина прочно вошли уже почти во все распространенные языки. Метапрограммирование тоже развивается, в частности в C#. Сплав из эти трех материалов и будет определять направление развития всех популярных языков на ближайшее будущее. Тут никуда ведь не деться, революций ожидать особо неоткуда, вектор стабильный. И, да, пользуясь случаем, хочу поблагодарить MS за лямбды, это дало хороший пинок неповоротливым Java&C++.
Не заметно, что это дало существенный профит самому микрософту.
__>>Я не хочу. Зачем мне такое дерьмо? _>А на чём сейчас программируют самые крутые программисты? Вот ты, например, на чём?
_>>А на чём сейчас программируют самые крутые программисты? __>Этого я не знаю . Спросите крутых программистов
Я это в общем предполагал, просто хотел получить информацию из первых рук. Обычно чем человек круче тем сильнее свою позицию аргументирует, прежде чем начать какашками кидаться
_>>Вот ты, например, на чём? __>Сейчас javascript, c#, python, немного С и PL/SQL. __>Также смотрю в сторону java и ruby, как на платформы которые возможно буду использовать в будущем. Нравится erlang, но этот интерес скорее академический; абсолютно уверен, что не буду использовать его в качестве языка программирования/платформы в реальных проектах.
Я просто почему спросил — думал может что-то появилось новое, своими возможностями разбившее на голову лучшие из существующих инструментов. Настолько крутое что можно начинать всё обсирать нести революцию в широкие массы быдлокодеров неосведомлённых программистов. Жаль, опять ошибся.
Ну так вводят же, а не выпиливают. То, что они тормоза это и так понятно, но у тормозов вектор движения меняется еще медленнее.
T>Не заметно, что это дало существенный профит самому микрософту.
Не понял. Мосье умеет заглядывать в альтернативную реальность? Что было бы с MS без .NET+C#?
Здравствуйте, hi_octane, Вы писали:
_>Я это в общем предполагал, просто хотел получить информацию из первых рук. Обычно чем человек круче тем сильнее свою позицию аргументирует, прежде чем начать какашками кидаться
Я не кидаюсь какашками, просто констатирую факт.
_>Я просто почему спросил — думал может что-то появилось новое, своими возможностями разбившее на голову лучшие из существующих инструментов. Настолько крутое что можно начинать всё обсирать нести революцию в широкие массы быдлокодеров неосведомлённых программистов. Жаль, опять ошибся.
Что по вашему "лучшие из существующих инструментов"? Может быть поясните свою мысль?
Здравствуйте, Ziaw, Вы писали:
T>>Не заметно, что это дало существенный профит самому микрософту.
Z>Не понял. Мосье умеет заглядывать в альтернативную реальность? Что было бы с MS без .NET+C#?
Как минимум перспективы микрософта в веб не улучшились ни на грам.
_>0)-18) _>19) Именованные индексаторы, типа string Name[int x, int y] { get { ... } set { ... } }, бывает нужно раз в год, и тут же вспоминаешь что по этой фиче паритет с VB нарушен.
Здравствуйте, icWasya, Вы писали:
_>>19) Именованные индексаторы, типа string Name[int x, int y] { get { ... } set { ... } }, бывает нужно раз в год, и тут же вспоминаешь что по этой фиче паритет с VB нарушен.
W>А кстати, почему это не сделали сразу? Не влезло по приоритетам.
надо добавить множественное наследие и generic с классами наследования, можно даже с какими-то ограничениями и syntax sugar'ом, а то некоторым любителям их отсутствие подрезает крылья.
Здравствуйте, Tanker, Вы писали:
T>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было
Я имею в виду, что все желаемое они давно могли бы получить проинсталировав на машину один msi.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>На самом деле нет, почитайте Липперта. У него половина блога — как раз о вопросах "почему нет фичи X"
Ну, да. У них времени нет. Все уходит на написание блога о том почему нет фичи X (тут цикл). Это каждый дурак может пойти и в нормальный расширяемый язык добавить нужную ему фичу. А вы попробуйте целый блог зполить вопросами почему нет фичи X!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, да. У них времени нет. Все уходит на написание блога о том почему нет фичи X (тут цикл). Это каждый дурак может пойти и в нормальный расширяемый язык добавить нужную ему фичу. А вы попробуйте целый блог зполить вопросами почему нет фичи X!
[кэп]
Помимо "запилить фичу" её неплохо бы покрыть тестами, документацией, поддержкой в IDE, убедиться, что она не поломает существующий код и т.д. и т.п. Это придётся делать вне зависимости от крутости фичи, ресурсы ограничены — приходится решать, что делать в первую очередь. Собственно, этим нормальный продукт и отличается от сделанного по принципу "потому что могу".
[/кэп]
Только плиз, давайте не будем холиварить на тему "А вот в ХХХ это добавляется за 0.1 сек, значит все кто не используют ХХХ — дураки и идиоты со синдромом блаба". И так чуть ли не полветки оффтопа.
Здравствуйте, icWasya, Вы писали:
_>>19) Именованные индексаторы, типа string Name[int x, int y] { get { ... } set { ... } }, бывает нужно раз в год, и тут же вспоминаешь что по этой фиче паритет с VB нарушен.
W>А кстати, почему это не сделали сразу?
У них был выбора: 1) реализовать именованные индексаторы (как в ВБ), б) придумать обоснование почему это не надо делать. Они взвесили все "за" и "против" и пришли к выводу, что придумать обоснование в 5 раз менее затратно. В итоге выбрали вариант (б).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>[кэп] S>Помимо "запилить фичу" её неплохо бы покрыть тестами, документацией, поддержкой в IDE, убедиться, что она не поломает существующий код и т.д. и т.п. Это придётся делать вне зависимости от крутости фичи, ресурсы ограничены — приходится решать, что делать в первую очередь. Собственно, этим нормальный продукт и отличается от сделанного по принципу "потому что могу". S>[/кэп]
Да, да. Именно этим они покрывают свои блоги. Там еще много подобной пурги.
S>Только плиз, давайте не будем холиварить на тему "А вот в ХХХ это добавляется за 0.1 сек, значит все кто не используют ХХХ — дураки и идиоты со синдромом блаба". И так чуть ли не полветки оффтопа.
Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да, да. Именно этим они покрывают свои блоги. Там еще много подобной пурги.
Ну блин. Ровно с той же аргументацией можно опустить любой язык:
1. Всё что говорят ваши оппоненты — пурга, язык отстой.
2. GOTO 1.
Ок, поставьте себя на место разработчиков шарпа. Первый релиз, одновременно с языком пишется весь BCL, winforms, asp.net, справка, средства для студии, учебники и курсы. Вообще не ясно, выстрелит ли язык, на всякий пожарный часть средств перекинута на васик/j#/mc++.
По срокам вы не успеваете добавить даже необходимые вещи типа генериков. Начальство требует релиз к сроку, т.к. маркетинг трубит про суперCOM++++ начиная с 99 года. Товарищи, которые только пощупали язык, обзывают явой в профиль и ругают за ненужные foreach, свойства, тормоза на топовых гигагерцовых процессорах и даже за enum-ы.
Ну как, будете добавлять именованные индексаторы?
VD>Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу".
Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?
Здравствуйте, Sinix, Вы писали:
S>Ну блин. Ровно с той же аргументацией можно опустить любой язык: S>1. Всё что говорят ваши оппоненты — пурга, язык отстой.
Было бы можно, если бы в этом языке не было бы указанных фич. А я знаю минимум два языка в которых имеется 90% предложенных фич.
S>Ок, поставьте себя на место разработчиков шарпа. Первый релиз, одновременно с языком пишется весь BCL, winforms, asp.net, справка, средства для студии, учебники и курсы. Вообще не ясно, выстрелит ли язык, на всякий пожарный часть средств перекинута на васик/j#/mc++.
Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет.
S>По срокам вы не успеваете добавить даже необходимые вещи типа генериков.
По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн. За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.
S>Начальство требует релиз к сроку, т.к. маркетинг трубит про суперCOM++++ начиная с 99 года. Товарищи, которые только пощупали язык, обзывают явой в профиль и ругают за ненужные foreach, свойства, тормоза на топовых гигагерцовых процессорах и даже за enum-ы.
Релиз C# был в 2002 году. Пилили его до этого несколько лет. Пилили не с нуля, а меняли Яву. Сегодня 2013 год. Прошло 11 лет.
Все предложенные для C# фичи были в Nemerle где-то в 2005 году. Nemerle в конце 2003 года.
S>Ну как, будете добавлять именованные индексаторы?
У меня они есть, так как я пишу на Nemerle. Причем есть уже около 7 лет. У тех кто пишет на VB они есть уже 11 лет.
VD>>Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу". S>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?
К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов.
И вообще, писать компилятор языке нужно исключительно на этом самом языке. Тогда будет стимул развивать язык, так как ты развиваешь его для себя любимого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов.
Обоснуй, плиз, выделенное.
S>На этом предлагаю закругляться — у меня аргументы закончились, еси продолжать, будем только по кругу ходить.
Как-то странно закругляться на самом интересном. Только до конкретики дошли...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinix, Вы писали:
S>>Ну блин. Ровно с той же аргументацией можно опустить любой язык: S>>1. Всё что говорят ваши оппоненты — пурга, язык отстой. VD>Было бы можно, если бы в этом языке не было бы указанных фич. А я знаю минимум два языка в которых имеется 90% предложенных фич.
Ну, один — это точно N, второй, подозреваю — VB, так?
N офигенен, без вопросов. Но это язык для энтузиастов. Для попадания в мейнстрим и в типовой энтерпрайз-софт нужно приложить огромное количество усилий по популяризации и поддержке.
Только один пример (без обид, я ни в коем случае не хочу опустить N. В большинстве некоммерческих проектов всё гораздо хуже ). Проблема разных версий dll в немерле всплыла уже после релиза
. Для мейнстрима — это однозначный фейл, каким крутым не был бы язык.
Да, у МС больше ресурсов (мягко говоря ), но они тоже небесконечны. Так что если выбирать между "фича A, без которой могут обойтись 80% пользователей" и "фича B без которой нас пошлют лесом 80% пользователей" — мой выбор очевиден. Тем более, что против фичи A есть серьёзный довод: именованные индексаторы не входят в CLS.
Если включить их в CLS — такие вещи надо будет добавить во все прочие языки под .NET.
Если не включать — какая-то часть API дотнета будет использовать вместо индексеров методы collection.get_Items(index)/collection.set_Items(index)
Повторюсь: в мейнстриме всё не так просто, как кажется
VD>Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет.
Угу. Напомнить, сколько по каждому из этих моментов было холиваров? Один только "Где мои указатели?!!! Я не хочу писать на бейсике!!!" всплывал раз 10 в месяц. ФП в то время вообще воспринималось как "это такой лисп? Что-то рассказывали, да", а на пике моды были ява и ООП.
VD>По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн.
Разработать и внедрить в продакшн — несколько разные вещи. Сам дизайн фичи — это хорошо если 10% затрат. Посмотрите, сколько усилий надо всего-то для добавления одного метода в API: тынц. Не, можно просто написать и выпустить, но тогда ровно столько же усилий уйдут на поддержку совместимостей со старыми версиями. Напомню, для мейнстрима даже 1% пользователей — это очень большие цифры. Если ничего не путаю, ещё в 2005м назывались цифры порядка 5 млн разработчиков (это не шарп, это все пользователи VS).
VD>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.
Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?
S>>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин? VD>К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов.
Не вариант. Никто не даст вам занять команду специалистов на 4 года (минимум) без релизов и гарантированного выхлопа.
Саммари: задним числом всё кажется элементарным. На деле это слегка не так.
На этом у меня с аргументами всё, если не убедил — сдаюсь
P.S. S>>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов. VD>Обоснуй, плиз, выделенное.
Написал выше по ветке.
Минусы: в шарпе нет иммутабельных переменных, следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении. Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.
Плюсы: отпал один довод в холиварах на тему "чего нет в шарпе".
Здравствуйте, Sinix, Вы писали:
S>Минусы: в шарпе нет иммутабельных переменных, следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении.
Каким образом C# уберегает от них сейчас и чем тут могут помочь иммутабельные переменные? Кстати, их введение очень дешево и совершенно не создает проблем обратной совместимости.
Да, и какие проблемы от побочных эффектов в выражении в императивном языке? Он специально проектируется для удобства создания побочных эффектов.
S>Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.
Не понимаю проблемы. Это вроде такого?
if (a)
if (b)
DoSomething();
// vsif (a && b)
DoSomething();
// vsvar condition = a && b;
if (condition)
DoSomething();
Программист регулярно и успешно решает эту проблему на уровне инстинктов (в зависимости от реальных a и b), не включая даже мозг. Нет, он конечно способен устроить холивар даже по этому поводу, но это ни о чем не говорит.
Здравствуйте, Sinix, Вы писали:
S>Ну, один — это точно N, второй, подозреваю — VB, так?
Второй Скала. Но в VB тоже пару фич есть, что нет в Шарпе.
S>N офигенен, без вопросов. Но это язык для энтузиастов. Для попадания в мейнстрим и в типовой энтерпрайз-софт нужно приложить огромное количество усилий по популяризации и поддержке.
Дык какие вопросы? Речь же идет о добавлении фич в Шарп. Фич давно проверенных на практике в других языках. Популяризацию шарпа уже произвели. Новые фичи только повысят ее.
S>Только один пример (без обид, я ни в коем случае не хочу опустить N. В большинстве некоммерческих проектов всё гораздо хуже ). Проблема разных версий dll в немерле всплыла уже после релиза
. Для мейнстрима — это однозначный фейл, каким крутым не был бы язык.
Хороший пример. Только это пример не из Немерла, а из .Net. В C# ее не видно просто потому что большая часть библиотек идет в составе фрэймворка. А ситуация когда есть две библиотеки созданные разными авторами и ссылающиеся на разные версии третьей библиотеки встречается крайне редко. Но ситуация таки встречается. Так что если это фэйл, то это фэйл МС.
S>Да, у МС больше ресурсов (мягко говоря ), но они тоже небесконечны.
Видимо именно по этому они тратят свои ресурсы попусту ведя разработку шарпа и дотнета на очень низкоуровневых языках вроде С++ и очень экстенсивными методами. Рослин, вот начали пилить через 10 лет после создания шарпа. И то боятся и осторожничают. А надо было сделать его в самом начале, а силы бросить на оптимизацию работы дотнета.
S>Так что если выбирать между "фича A, без которой могут обойтись 80% пользователей" и "фича B без которой нас пошлют лесом 80% пользователей" — мой выбор очевиден.
80%, очевидно, не видят дальше своего носа и ни послать не могут, ни требовать ничего не будут. Вот кто требовал появления ЛИНК-а? Хомячки хотели, в лучшем случае, Хибернэйт от МС. А тут такое.
S> Тем более, что против фичи A есть серьёзный довод: именованные индексаторы не входят в CLS.
В метаданных индексаторы именованные отличаются от не именованных только, простите за коломбур, именем. У неименованного (поддерживаемого шарпом) имя Item.
S> Если включить их в CLS — такие вещи надо будет добавить во все прочие языки под .NET.
Все прочие — это БВ? Так там они уже есть. А в МС++ и индексаторов то нет. Так что с него не убудит.
Короче, это все бестолковые оправдания.
Собственно я не знаю, что ты так уперся в эти индексаторы. Они мало кому интересны. А вот другие перечисленые не делаются уже очень давно и с такими же притянутыми за уши оправдениями.
Меж тем МС героически пилит отдельный компилятор на С++ и еще языковый сервис на том же С++, которые на 80% повторяет компилятор.
Несколько лет назад, когда в МС еще не вилась работа над Рослином, нам (как сейчас про индексеры) объяснял, что совместить языковый сервис и компилятор невозможно. Им говорили — помилуйте, вот же Немерл у которого это именно так. Но им было по фигу. Они строчили блоги в которых убедительно (для тех кто не в теме) "доказывали" бесполезность совмещения компилятора и языкового сервиса.
Настали новые времена. В МС поменяли мнение и теперь даже не вспоминают, что несли чушь.
Так же будет и по остальным вопросам.
S> Если не включать — какая-то часть API дотнета будет использовать вместо индексеров методы collection.get_Items(index)/collection.set_Items(index)
Ах ты божеж мой?! Какая печалька! А сейчас что не та? Как на МС++ вызвать индексаторы?
S>Повторюсь: в мейнстриме всё не так просто, как кажется
Читайте меньше советских газет перед едой блогов.
VD>>Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет. S>Угу. Напомнить, сколько по каждому из этих моментов было холиваров?
Напомнить. Я помню только дин. Про то какие делегаты кривые.
S>Один только "Где мои указатели?!!!
Они то как раз и были в Шарп добавлены. В оригинале (Яве) их не было.
S>Я не хочу писать на бейсике!!!" всплывал раз 10 в месяц. ФП в то время вообще воспринималось как "это такой лисп? Что-то рассказывали, да", а на пике моды были ява и ООП.
Сегодня вот ситуация в корне другая. Люди спрашивают "где мой паттерн-матчинг и АлгТД?", а им в ответ пишут блоги в ктоторых объясняют почему их не будет.
VD>>По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн. S>Разработать и внедрить в продакшн — несколько разные вещи.
Да, да. Заработать в сто раз сложнее. Этот процесс не распараллелить. А Дон не только придумал дизайн, но и реализовал его. В МС оставлось подправить баги и языковый сервис. Если бы сервис и компилятор имел общую кодовую базу, то второе и делать не надо было бы.
S>Сам дизайн фичи — это хорошо если 10% затрат.
Трепач находка для шпиенов. (с) мой отец
S>Посмотрите, сколько усилий надо всего-то для добавления одного метода в API: тынц.
Это плагиат. В оригинале было так:
— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!
(с) Формула любви
S>Не, можно просто написать и выпустить, но тогда ровно столько же усилий уйдут на поддержку совместимостей со старыми версиями.
С дуру можно и...
VD>>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать. S>Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?
Имеется в виду:
class A<T>
{
class B
{
T x; // здесь доступен параметр типа внешнего типа
}
}
Учитывая, что типы часто используют для сокрытия областей видимости это приводит к неочевидным проблемам. А уж сокрытие параметров типов это вообще смешно.
S>>>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин? VD>>К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов. S>Не вариант. Никто не даст вам занять команду специалистов на 4 года (минимум) без релизов и гарантированного выхлопа.
Ты явно не подумал прежде чем это сказал. Они они все равно написали отдельный компилятор и отдельный языковый севрис. Но сделали это на более низкоуровневом языке и в двое большими силами.
S>На этом у меня с аргументами всё, если не убедил — сдаюсь
Да нет у тебя аргументов. Ты защищаешь заведомо проигрышную позицию.
Реальные аргументы (которые не высказываклись) были следующими:
1. В МС не было нужного числа программистов пишущих на Шарпе/Яве.
2. У дотнета плохо с производительностью.
3. В МС не дальновидные ПМ-ы.
Но кто же в таких проблемах признается то? Вот и несут в блогах разную пургу.
S>P.S. S>>>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов. VD>>Обоснуй, плиз, выделенное. S>Написал выше по ветке.
Не заметил.
S>Минусы: в шарпе нет иммутабельных переменных,
1. За чем дело стало?
2. В Шаре есть неизменяемые переменные: переменные из foreach, using, let и поля с модификатором readonly неизменяемы.
S>следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении.
Да, да. А в экспрешонах проблем нет:
Foo(a = ++b)
И в Nemerle/F#/Scala тоже побочные эффекты где угодно могут быть. Это ни разу не проблема.
S>Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.
У нас и без этого выше крыши возможностей написать одно и тоже разными способами. Напрмер, черз Линк и фиклами (решарпер даже одно в другое конвертирует в автомате). Это не помешало ввести тот же Линк.
S>Плюсы: отпал один довод в холиварах на тему "чего нет в шарпе".
Тогда не надо было свой язык делать. Реализовали бы Яву и жили бы счастливо.
Короче вся твоя аргументация не выдерживает элементарной критики. Это потому, что ты защищаешь то что защищать не следует.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
T>>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было
VD>Я имею в виду, что все желаемое они давно могли бы получить проинсталировав на машину один msi.
Это вобщем враньё или от недомыслия. Первый вопрос у менеджера — насколько сложно искать специалистов. Заходит к HR — они делают круглые глаза и вопрос отпадает само собой. Второй вопрос — сможет ли новичек в программировании поднять код на этом языке. Показывают новичку PM , не говоря про макры, новичек делает круглые глаза и вопрос снова отпадет. Третий вопрос — насколько качественный инструменты. Четвертый — насколько стабильный релиз. После ответа на эти вопросы можно начинать думать про инсталятор. А у тебя на инсталяторе все только начинается.
Здравствуйте, VladD2, Вы писали:
T>>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было
VD>Я имею в виду, что все желаемое они давно могли бы получить проинсталировав на машину один msi.
Вот берем в качестве примера BLT, который ИТ фиксил шоб всунуть его в тот язык, который умеет Немерле но является якобы С#.
Ты предложил переписать часть кода, которая не работала, на Немерле. ИТ похоже идея не сильно понравилась.
Примерно так же будет и в энтерпрайзе. В маленькую команду можно всунуть все что хочешь.
Здравствуйте, VladD2, Вы писали:
VD>>>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать. S>>Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?
VD>Имеется в виду: VD>
VD>class A<T>
VD>{
VD> class B
VD> {
VD> T x; // здесь доступен параметр типа внешнего типа
VD> }
VD>}
VD>
а что тут не так? VD>Учитывая, что типы часто используют для сокрытия областей видимости
что вы имеете в виду? VD> это приводит к неочевидным проблемам.
каким? VD>А уж сокрытие параметров типов это вообще смешно.
можно подробнее?
Здравствуйте, DarkGray, Вы писали:
AVK>>Для этого придется сделать совершенно другой язык. В рамках существующего шарпа это невозможно.
DG>это делается через зависимые типы, и это вполне можно сделать в шарпе
а как быть с полями структур? их надо чем-то инициализировать по умолчанию.
DG>>это делается через зависимые типы, и это вполне можно сделать в шарпе C>а как быть с полями структур? их надо чем-то инициализировать по умолчанию.
Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.
Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.
DG>>>это делается через зависимые типы, и это вполне можно сделать в шарпе C>>а как быть с полями структур? их надо чем-то инициализировать по умолчанию.
DG>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.
а что делать с обратной совместимостью?
DG>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.
придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью?
DG>>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру. C>а что делать с обратной совместимостью?
Поведение старых типов останется таким же, как и было, а вот стандартную либу желательно перегрузить, чтобы она одновременно могла работать и со строками, которыми могуть быть null, и которые не могут быть null, тоже самое и с коллекциями.
В целом это очень похоже на то, как в .net была добавлена covariance contravariance семантика.
DG>>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора. C>придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью?
Обязателен он только для типов, для которых объявлено, что они не могут быть null, соответственно, проблем с совместимостью не много.
Здравствуйте, AndrewVK, Вы писали:
VD>>И вообще, писать компилятор языке нужно исключительно на этом самом языке.
AVK>Новый компилятор шарпа написан на шарпе, причем на данный момент он компилирует сам себя.
Я в курсе. Вот только нужно было сделать это 10 лет тому назад.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
DG>>>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру. C>>а что делать с обратной совместимостью?
DG>Поведение старых типов останется таким же, как и было,
т.е. в старом коде ошибка выдаватся не будет? DG>а вот стандартную либу желательно перегрузить, чтобы она одновременно могла работать и со строками, которыми могуть быть null, и которые не могут быть null, тоже самое и с коллекциями.
стандартную библиотеку придется продублировать. к старой версии дописать такую же, но с новыми типами. DG>В целом это очень похоже на то, как в .net была добавлена covariance contravariance семантика.
не вижу аналогий.
DG>>>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора. C>>придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью? DG>Обязателен он только для типов, для которых объявлено, что они не могут быть null, соответственно, проблем с совместимостью не много.
т.е. прощай контекстно свободная грамматика? (т.е. она конечно уже давно не контекстно свободная)
У кого и что сломается?
