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

КД>Полюбил я ключевое слово var всей душой и телом.

Эт хорошо!

КД> И юзаю его везде где только можно.

А вот эт ты зря. Как и любую возможность любого языка программирования, ее нужно использовать ни "где только можно", а "где только нужно". А то это мне анекдот про кота напоминает

Я полностью "за" использование var-a и применяю его очень часто, но есть моменты, пусть и очень-очень редкие, когда без понимания четкого типа переменной понять, что происходит в коде сложно. Повторюсь, я за эту штуку, но категоричность глаз режет.

КД>И сильно расстроился когда компилятор (VS2010) ниасилил
КД>

КД>class Program
КД>{
КД> private static var sm_Tests=new List<int>();
КД>};//class Program
КД>

КД>Ну что за ботва!

ИМО у этой ботвы есть несколько причин.
1. Никто не хотел сделать C# 3.0 полностью неявнотипизированным языком программирования, типа F#-а, где все типы выводились бы компилятором. Неявная типизация прежде всего являлась одной из составляющих (пусть и важной) более общей концепции под названием LINQ. Поскольку результатами LINQ-запросов могли быть последовательности анонимных классов, то без этой возможности мы бы получили слишком урезанные возможности LINQ-а.

Неявно-типизированные поля же никоим образом делу LINQ-а помочь не могли.

2. Даже с первого взгляда тут появляются ряд вопросов к использованию var-а в полях.
Да, я понимаю, что можно ограничить использование var-а только field-like инициализацией и выдавать ошибку при попытке записи чего-то типа:

class Program
{
  var c;
}

Так что с предыдущим комментом проблем никаких.

Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

class A
{
  public var field = new {I = 1, S = "2"};
}

В результате мы получили бы класс, чей открытый интерфейс не пойми как использовать. Ведь анонимные классы — это закрытые классы, которые генерируются внутри текущей сборки и, по идее, использованы снаружи быть не могут. Конечно, можно было бы ограничить использование var только для внутренних (internal) полей, но, согласитесь, было бы странно, что мы можем некоторую языковую возможность использовать с одним модификатором доступа и не можем — с другим.

Можно было бы запретить использование анонимных классов для инициализации неявно-типизированных полей, но тогда мы бы получили дикую несогласованность, поскольку две "родственные" фичи: а именно, неявно-типизированные локальные переменные и поля, не могли бы использоваться в одних и тех же условиях.

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

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

КД>Привет всем.

КД>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

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

S>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Привет всем.

КД>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

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

Привет всем.

Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

И сильно расстроился когда компилятор (VS2010) ниасилил

class Program
{
 private static var sm_Tests=new List<int>();
};//class Program

Ну что за ботва!

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

А>То "new List<int>();" происходит в конструкторе, путь и статическом, но конструкторе. И получается объявление вида:
А>"private static var sm_Tests;"
А>И действительно не понятно, какой тип должна иметь эта переменная. Конечно, это могли бы и обойти, но видимо не захотели...

Вывод типа делается в момент компиляции и без разницы, где делается какой вызов.
Соответсвенно компилятор может вывести тип как для мембера, так и для параметра и вообще для чего угодно.

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

КД>

КД>static void test_method()
КД>{
КД> var x;
КД>}
КД>

КД>Какой тип имеет переменная x?

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

So immediately we have one problem; if we have "var" fields then the type of the field cannot be determined until the expression is analyzed, and that happens after we already need to know the type of the field.

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

Тут дело не в том, что компилятор не осили вывод типов, а в том что var может использоваться только при объявлении локальных переменных.
http://msdn.microsoft.com/en-us/library/bb383973.aspx

Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var.

КД>Какой тип имеет переменная x?

Дело в том, что когда Вы пишите:
class Program
{
private static var sm_Tests=new List<int>();
};//class Program

То "new List<int>();" происходит в конструкторе, путь и статическом, но конструкторе. И получается объявление вида:
"private static var sm_Tests;"
И действительно не понятно, какой тип должна иметь эта переменная. Конечно, это могли бы и обойти, но видимо не захотели...

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

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

С var будет показан настоящий тип, а не var.

S>непонятно совершенно — где его применение еще может быть оправдано.

Ну, например, при перечислении в foreach элементов словаря, приятнее написать var, а не KeyValuePair<TKey, TValue>. Я против употребления var везде где можно, но бывают какие-то совсем очевидные и весьма многословные случаи.

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

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

S>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>Привет всем.

КД>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
Скорее всего эту ветку нужно перенести в священные войны
Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

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

КД>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.
Д>И сильно расстроился когда компилятор (VS2010) ниасилил
КД> private static var sm_Tests=new List<int>();
КД>Ну что за ботва!

Всё элементарно — шарпоклепатели а-ля Липперт написали компилятор, неспособный выводить тип полей класса — var работает только в пределах методов. Напрягать зад, чтобы кто-то вместо Dictionary<int, string> написал var — им лениво, возможно даже это потребовало бы переписывания трети компилера. В результате Липперт пишет гнилые отмазки, позорясь на весь тырнет, но делая это с умным видом.
Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ, весь вопрос только в архитектуре компилера. Возможно даже это прогиб под студию, чтобы та побыстрее интеллисенсила — граблесофт и не такое может.

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

A>>Вы либо добросовестно заблуждаетесь, либо троллите. Тут уже писали, что .Net разделяет код на сборки и это вносит свои коррективы.
M>Бросайте это школоло "тролите"! Никому ваши нервы не упёрлись. Возможно, я заблуждаюсь, но в упор не вижу разницы между типизацией поля и локальной переменной. Поясните, причём тут сборки?

сборка А

public class MyA
{
  public static int GetLength();
}

сборка B

public class MyB
{
  public static var Length = MyA.GetLength();
}

сборка C

public class MyС
{
  public static var BLength = MyB.Length;
}

Поменяли сборку А, на следующее

public class MyA
{
  public static BigInteger GetLength();
}

Что должно происходить в сборках B и С?

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

ST>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>

ST>class A
ST>{
ST>  public var field = new {I = 1, S = "2"};
ST>}
ST>

ST>В результате мы получили бы класс, чей открытый интерфейс не пойми как использовать.

Здесь проблема лежит глубже. Такой код вполне имеет право на существование... в рамках структурной типизации. Рано или поздно разработчики C# таки упрутся в систему типов дотнета, конечно хотелось быть чтобы это случилось раньше.

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

КД>>Какой тип имеет переменная x?

А>Дело в том, что когда Вы пишите:
А>class Program
А>{
А> private static var sm_Tests=new List<int>();
А>};//class Program

А>То "new List<int>();" происходит в конструкторе, путь и статическом, но конструкторе. И получается объявление вида:
А>"private static var sm_Tests;"
А>И действительно не понятно, какой тип должна иметь эта переменная. Конечно, это могли бы и обойти, но видимо не захотели...

Позволю себе позанудствовать: это происходит НЕ в статическом конструкторе. Между такой инициализацией полей и статическим конструктором есть разница.

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

A>>>Какой тип имеет переменная foo?
A>>>Если очень хочется, то есть dynamic.

КД>>

КД>>static void test_method()
КД>>{
КД>> var x;
КД>>}
КД>>

КД>>Какой тип имеет переменная x?

L>Никакого. Код не скомпилится.

А вот хрена лысого

class t_test
{
 class var
 {
 };

 static void test()
 {
  var x;
 }//test
};//class t_test

Пожалуй добавлю я еще очков adontz-у за ссылку на доку

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

L>>Никакого. Код не скомпилится.

КД>А вот хрена лысого
КД>

КД>class t_test
КД>{
КД> class var
КД> {
КД> };

КД> static void test()
КД> {
КД>  var x;
КД> }//test
КД>};//class t_test
КД>

КД>

Этот код отличается от предыдущего кода.

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

S>>С точки зрения читателя такого кода, это очень неудобно.
S>>Это создает лишние трудности для его понимания.
S>>Выглядит это просто так, что человеку лень даже тип указать.
S>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

КД>Коротко говоря — лично мне все это по-барабану

КД>Потому что меня прёт

Слова не мальчика, но мужа

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

VS>У нас правила такие: var использовать только тогда, когда тип переменной очевиден из ее объявления, для исключения дублирования:

Есть ещё случаи, когда тип не важен.

protected virtual void OnSomeActionDoing(SomeActionEventArgs eventArgs)
{
    var eventHandler = SomeActionDoing; // Пофиг!

    if (eventHandler != null)
    {
        eventHandler(this, eventArgs); // Этот код не поменяется. Судьба.
    }
}

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

S>Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

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

Надо быть последоватальным — если простые случаи использвания var "вводят в заблуждение" то и в "сложных" его использовать не стоит.

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

A>Поменяли сборку А
A>Что должно происходить в сборках B и С?

Ничего не должно происходить — сборки B и С заблаговременно были сохранены на запароленой флешке

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

A>Тут дело не в том, что компилятор не осили вывод типов, а в том что var может использоваться только при объявлении локальных переменных.
A>http://msdn.microsoft.com/en-us/library/bb383973.aspx

A>

A>Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var.

Ага, спасибо. Я пока еще не натаскался на все эти ограничения и пишу методом проб и ошибок

И, ясный пень, в документацию не смотрю смотрю через раз

The following restrictions apply to implicitly-typed variable declarations:

• var can only be used when a local variable is declared and initialized in the same statement; the variable cannot be initialized to null, or to a method group or an anonymous function.
  
  
• var cannot be used on fields at class scope.
  
  
• Variables declared by using var cannot be used in the initialization expression. In other words, this expression is legal: int i = (i = 20); but this expression produces a compile-time error: var i = (i = 20);
  
  
• Multiple implicitly-typed variables cannot be initialized in the same statement.
  
  
• If a type named var is in scope, then the var keyword will resolve to that type name and will not be treated as part of an implicitly typed local variable declaration.

Отюда

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

A>Здравствуйте, Коваленко Дмитрий, Вы писали:

A>Тут дело не в том, что компилятор не осили вывод типов, а в том что var может использоваться только при объявлении локальных переменных.
A>http://msdn.microsoft.com/en-us/library/bb383973.aspx

A>

A>Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var.

только вот зачем такое ограничение сделали — не понятно.

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

J>только вот зачем такое ограничение сделали — не понятно.

public class Bar
{
    private var foo;
}

Какой тип имеет переменная foo?
Если очень хочется, то есть dynamic.

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

J>>только вот зачем такое ограничение сделали — не понятно.

A>

A>public class Bar
A>{
A>    private var foo;
A>}
A>

A>Какой тип имеет переменная foo?
A>Если очень хочется, то есть dynamic.

static void test_method()
{
 var x;
}

Какой тип имеет переменная x?

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

КД>>Какой тип имеет переменная x?

А>Дело в том, что когда Вы пишите:
А>class Program
А>{
А> private static var sm_Tests=new List<int>();
А>};//class Program

А>То "new List<int>();" происходит в конструкторе, путь и статическом, но конструкторе. И получается объявление вида:
А>"private static var sm_Tests;"
А>И действительно не понятно, какой тип должна иметь эта переменная. Конечно, это могли бы и обойти, но видимо не захотели...

Вот — фактически ответ на вопрос!

А я ведь читал (и даже перечитывал) про эту инициализацию членов класса.

Но не увязал с этой проблемой

---
Жаль что не захотели

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

A>>Какой тип имеет переменная foo?
A>>Если очень хочется, то есть dynamic.

КД>

КД>static void test_method()
КД>{
КД> var x;
КД>}
КД>

КД>Какой тип имеет переменная x?

Никакого. Код не скомпилится.

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

L>>>Никакого. Код не скомпилится.

КД>>А вот хрена лысого

L>Этот код отличается от предыдущего кода.

Ага, но все равно прикольно

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

R>Позволю себе позанудствовать: это происходит НЕ в статическом конструкторе. Между такой инициализацией полей и статическим конструктором есть разница.

Инициализация происходит в статическом конструкторе, класс помечается аттрибутом beforefieldinit

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

КД>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>С точки зрения читателя такого кода, это очень неудобно.
S>Это создает лишние трудности для его понимания.
S>Выглядит это просто так, что человеку лень даже тип указать.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

Коротко говоря — лично мне все это по-барабану

Потому что меня прёт

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

S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

Дело привычки. Люди, пишущие на динамических языках вон привыкли и не жалуются. В случае же C# это просто синтаксический сахар (исключая случаи анонимных типов и LINQ), как foreach.

S>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

У нас правила такие: var использовать только тогда, когда тип переменной очевиден из ее объявления, для исключения дублирования:

OK:

var my = new My();
var my = GetInstance<My>();
var my = obj as My;
var my = (My) obj;

Не OK:

var my = GetInstance();
foreach (var my in _allMy){}

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

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

AN>Здравствуйте, k.o., Вы писали:

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

S>>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>>Привет всем.

КД>>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
AN>Скорее всего эту ветку нужно перенести в священные войны


AN>Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

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

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

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

AN>>Здравствуйте, k.o., Вы писали:

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

S>>>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>>>Привет всем.

КД>>>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>>>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
AN>>Скорее всего эту ветку нужно перенести в священные войны
KO>

AN>>Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

KO>Эту позицию (никогда не использовать var), хотя бы, можно понять, она последовательна и логична, а вот то, что было озвучено выше выглядит, честно говоря, бредово.
А вот бредовость утверждения никак не доходит, только если не подразумевается распечатка проги и мыша (но это думаю и не имелось в виду).

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

ST>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>

ST>class A
ST>{
ST>  public var field = new {I = 1, S = "2"};
ST>}
ST>

Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

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

A>Есть ещё случаи, когда тип не важен.

A>

A>protected virtual void OnSomeActionDoing(SomeActionEventArgs eventArgs)
A>{
A>    var eventHandler = SomeActionDoing; // Пофиг!

A>    if (eventHandler != null)
A>    {
A>        eventHandler(this, eventArgs); // Этот код не поменяется. Судьба.
A>    }
A>}
A>

Следует заметить, что это вообще "трубопроводный" и второстепенный код, которого в идеале лучше бы вообще не было целиком.

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

A>Дело привычки. Люди, пишущие на динамических языках вон привыкли и не жалуются. В случае же C# это просто синтаксический сахар (исключая случаи анонимных типов и LINQ), как foreach.

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

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

А>Здравствуйте, SergeyT., Вы писали:

ST>>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>>

ST>>class A
ST>>{
ST>>  public var field = new {I = 1, S = "2"};
ST>>}
ST>>

А>Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

Извиняюсь, не в тему ответил. Я написал о проблемах с типизацией, а у вас речь шла о том, что анонимный класс будет закрытым. Ну, делать открытые данные вообще неправильно. Можно и запретить делать такие открытые данные, а можно и разрешить, в чем проблема-то? Ну сгенерирует для него компилятор класс с каким-нибудь нелепым названием, ну и ладно.

Короче говоря, мне все эти аргументы кажутся надуманными. А то C# начинает напоминать C++, автор которого тоже не следовал принципу "сказал А, говори Б". Там тоже много таких моментов "здесь можно, а тут нельзя", "тут помню, тут не помню". Надо было или не делать вывод типов вовсе, или делать полноценно.

Лично я считаю вывод типов в C# ошибкой.

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

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

А потом они колбасят форум вопросами о том как в .Net сделають структурную типизацию и выясняется что никак и компилятор поддерживает неизвестно что.

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

ST>>>

ST>>>class A
ST>>>{
ST>>>  public var field = new {I = 1, S = "2"};
ST>>>}
ST>>>

А>Извиняюсь, не в тему ответил. Я написал о проблемах с типизацией, а у вас речь шла о том, что анонимный класс будет закрытым. Ну, делать открытые данные вообще неправильно. Можно и запретить делать такие открытые данные, а можно и разрешить, в чем проблема-то? Ну сгенерирует для него компилятор класс с каким-нибудь нелепым названием, ну и ладно.

То, что открытые поля делять неправильно совсем не означает, что это невозможно. Кроме того, существуют классы, единственная обязанность которых — это хранение данных. И в них, как раз очень часто используется field-like инициализация, что делает эти классы отличным кандидатом на использование этой фичи.

Если честно, то когда я писал ответ на этот вопрос, то о существовании приведенного ранее поста Эрика даже и не знал. Поэтому исходил из тех предпосылок, которые родились самостоятельно в голове. При этом в ответе я постарался свести плюсы с минусами, чтобы можно было сделать вывод, насколько эта фича актуальна. Я сделал вывод, что в текущих условиях плюсы от нее не перевешивают минусы.

А>Короче говоря, мне все эти аргументы кажутся надуманными. А то C# начинает напоминать C++, автор которого тоже не следовал принципу "сказал А, говори Б". Там тоже много таких моментов "здесь можно, а тут нельзя", "тут помню, тут не помню". Надо было или не делать вывод типов вовсе, или делать полноценно.

Мир жесток, несправедлив и, вообще, не идеален.

Дело все в том, что логика должна быть обратной: вместо того, чтобы доказывать, почему ту или иную фичу никто не будет делать нужно доказать, почему ее делать стоит. Вот таких доказательств для фичи, которая может быть использована лишь в ограниченном количестве случаев, я не вижу. Поправьте, если ошибаюсь.

А>Лично я считаю вывод типов в C# ошибкой.

Аргументированное заявление.

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

M>Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ.

Вы либо добросовестно заблуждаетесь, либо троллите. Тут уже писали, что .Net разделяет код на сборки и это вносит свои коррективы.

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

А>Здравствуйте, SergeyT., Вы писали:

ST>>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>>

ST>>class A
ST>>{
ST>>  public var field = new {I = 1, S = "2"};
ST>>}
ST>>

А>Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

В Nemerle так тоже делать нельзя
Одна из причин замедление компиляции.

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

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

M>>Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ.

A>Вы либо добросовестно заблуждаетесь, либо троллите. Тут уже писали, что .Net разделяет код на сборки и это вносит свои коррективы.

Бросайте это школоло "тролите"! Никому ваши нервы не упёрлись. Возможно, я заблуждаюсь, но в упор не вижу разницы между типизацией поля и локальной переменной. Поясните, причём тут сборки?

По идее, в каком бы виде поле ни записывалось, оно обрабатывается компилером. Только в одном случае нас вынуждают писать "тип имя", а в другом можно "var имя = НекийВычислимыйТип" — компилеру так сложно пройтись по "НекийВычислимыйТип"?

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

M>Возможно, я заблуждаюсь, но в упор не вижу разницы между типизацией поля и локальной переменной.

А полноценной типизации для "локальной переменной" тоже нет. Если только типизация из инициализатора (выражение справа от присваивания).
И разница между нормальным выводом типов и тем "выводом типов", что есть в шарпе — очень большая.

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

A>Что должно происходить в сборках B и С?
Перемести этот код в методы. Что изменится?

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

A>>Что должно происходить в сборках B и С?
WH>Перемести этот код в методы. Что изменится?

Это уже не будут разные сборки.

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

A>Это уже не будут разные сборки.
Да правда что ли?
сборка А

public class MyA
{
  public static int GetLength();
}

сборка B

public class MyB
{
  public static void Foo()
  {
        var length = MyA.GetLength();
    }
}

Сборку B один хрен перекомпилировать, ибо тип поменялся.

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

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

WH>Сборку B один хрен перекомпилировать, ибо тип поменялся.

У меня не зря было три сборки.

WH>Я тебе больше скажу, что с var что с явным указанием типа все будет точно так же.
WH>Никакой разницы.

Разница в объёме работы, который необходимо проделать компилятору. С такими "удобствами" можно очень скоро приехать во времена Си++, когда компиляция занимает десятки минут.

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

WH>>Сборку B один хрен перекомпилировать, ибо тип поменялся.
A>У меня не зря было три сборки.
Зря. Разници никакой.

A>Разница в объёме работы, который необходимо проделать компилятору. С такими "удобствами" можно очень скоро приехать во времена Си++, когда компиляция занимает десятки минут.
В С++ вывода типов нет. Там другое тормозит.

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

WH>>>Сборку B один хрен перекомпилировать, ибо тип поменялся.
A>>У меня не зря было три сборки.
WH>Зря. Разници никакой.

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