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

K>извиняюсь, действительно упустил.
K>btw, проверил этот сценарий в котлине — он ругается и не дает скомпилить.

В котлике есть неизменяемые локальные переменные. Для них этот прокатывает. Хотя, все равно дизайн спорный выходит. В немерле можно использовать стандартный ПМ:

when (x is Y as y)
{
  ...
}

"y" имеет тип "Y" и является неизменяемой переменной. В "x" по прежнему можно присваивать новое значение (если она изменяемая) и тип у него прежний.

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

IT>>И чего оно такого дублирует?

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

А чё ж с виртуальными то? Без них было бы проще?

А is/as их не дублирует? А то я тут много кода видел с is/as вместо "обычных виртуальных методов".

Об остальном я уже рядом написал.

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

S>А какая проблема в дублировании? В F# и Nemerle есть и обычные классы и АлгТД

Это не объектно-ориентированно! Вот то ли дело энумы в Яве?!

Хомечкам порвет мозг от возможности сделать что-то двумя путями. Пусть лучше паттернами проектирования пользуются и is/as-ами. А то не дай бок прострелят себе ногу не в том мести, а МС отвечать за это.

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

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

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

К тому же 90% хотелок, описанных в этой теме, реализуются без изменения рантайма.

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

G>Вообще есть вероятность нарушения LSP при таком поведении.

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

Ковариантность для возвращаемых значений работает в С++ и Яве.

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

S>вот это уже ковариантность.
S>

S>object[] = new int[] { 1 };
S>

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

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

G>object[] x = new int[] { 1 };

ЩИТО?

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

VD>В общем, если у них проблемы с дизайном, могу за скромную сумму (ну, скажем 10К зеленых) спроектировать поддержку ПМ для шарпа, что называется под ключ (с грамматикой и описанием семантики).

Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.

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

IT>Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.

Я не против. Все равно по сравнению с их затратами это демпинговые цены. Они же фичу рожают по два года и коллективно.

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

AVK>Соответственно, от вас хотелось бы получить те фичи, которых не хватает лично вам.

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

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

Я бы предложил им переписать компилятор, чтобы намного сильнее увеличить уровень оптимизации. Что-то типа LTCG (именно на уровне байт кода) было бы здорово получить.

Записывать guid без кавычек и прочих выкрутасов, как обычное число.
Не

id = new Guid("218a8084-1e3d-4afa-8783-41df0147032d")

а

id = g218a80841e3d4afa878341df0147032d

или ещё лучше в base64 (24 символа)

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

IT>>Могу за 20K в аналогичной валюте сделать ревью дизайна Влада. Если оно окажется типа "Всё OK", то всё равно бабки вперёд.
VD>Я не против. Все равно по сравнению с их затратами это демпинговые цены. Они же фичу рожают по два года и коллективно.
Работая в продуктовой конторе, могу вас, пацаны, разочаровать. В нужную работу, помимо проектирования и review, входит также мейнтенанс на пять лет вперёд (т.е. участие в дизайне всех будущих фич с учётом наличия этой существующей) и саппорт на десять лет вперёд (то есть помощь несчастным хомячкам, выстрелившим себе в ногу при помощи вашей фичи).
Стоимостью реализации при таких раскладах можно смело пренебречь. А запрошенные вами 30к на двоих эти две активности сожрут уже к концу 2014. Дальше вы будете работать себе в убыток.

А если вы откажетесь от этих "обременений" — то Редмонд ваше предложение никак не заинтересует. У них и своих проектировщиков хватает; с учётом ихних зарплат, проект+ревью им обойдётся тыщи в четыре, от силы в пять.

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

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

SAS>Нельзя ли сделать так, чтобы enum'ы реализовывали интерфейс IEquatable<> ?
А блоки итераторов — интерфейс ICloneable<>.

Здравствуйте, Osaka, Вы писали:
O>или ещё лучше в base64 (24 символа)
Стесняюсь спросить — а зачем?
Я бы ещё понял compile-time checking гуидных констант.
Но он сам по себе никак не требует переписывания кода — я бы скорее попросил валидации всех выражений new Guid(expr), если expr резолвится в string constant.
А экономить десяток байт в ущерб читаемости, имхо, нездоровая идея.

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

Очень хотелось бы Dispose по exception. Пример, примерно такой:

class MyClass:IDisposableException
{
   public MyClass(Context c){...}
   public void Dispose(){ context.Commit();}
   public void Dispose(Exception e)
   {
    context.Rollback();
    Log.Exception(e);
    throw;
   }
}

void main()
{
   using(new MyClass(new Context()))
   {
/// do something
   }
}

Синтаксический сахар вырождается примерно в структуру:

void main()
{
   var myClass=new MyClass(new Context());
   bool bDisposed;
   try
   {
///do something
   }
   catch(Exception e)
   {
      myClass.Dispose(e);
      bDisposed=true;
   }
   finally
   {
      if (!bDisposed)
          myClass.Dispose();
   }

}

Доработка простая как 2 копейки. Но периодически её сильно не хватает.

Да и еще хотелось бы иметь switch по типам. Лучше даже в виде проверки is.

switch (myObj)
{
   case typeof(MyClass):....
   case typeof(MyClass2):....
}

Ручной полиморфизм иногда пригождается. Кроме того он более управляем, чем перегрузка методов.

O>>или ещё лучше в base64 (24 символа)
S>Стесняюсь спросить — а зачем?
Меньше занимает места на экране.

S>Стесняюсь спросить — а зачем?
А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).

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

O>

id = g218a80841e3d4afa878341df0147032d

И как понять компилятору: это guid или переменная?

Зарезервируем все guid-ы?

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

S>>Стесняюсь спросить — а зачем?
O>А вообще идея возникла из неудобного выделения мышью (надо бы как число или слово — dblclick в 1 точке, а приходится вручную выцеливаться в начало и конец).
Двойной щелчок перед открывающей кавычкой пробовали?