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

L>И почему в таком случае не будет проблем после прокручивания внешнего enumerable-а? У стрима position будет на конце и дальнейшая работа с внешним enumerable-ом будет обламываться.

Если будет обламываться, то это очень хорошо. Тебе же вроде как не нравится нежелательное поведение, а не обломы.

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

L>Я рад за вас. Ты задал вопрос, я на него ответил. Пример из реальной жизни.

Только твой пример как-то часто меняются.

L>Проблема возникает именно из-за ленивой природы линковских запросов. Использование var скрывает проблему. Не-использование выставляет ее напоказ.

Такие скрытия в нашей жизни происходят постоянно. Вот тебе, например, типичные скрытия:

myObj.Foo().Bar();

Какой тип возвращает Foo? Или ты тоже в таких случаях всегда заводишь локальную переменную, чтобы не дай бог не ошибиться?

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

LL>>>Нет, в моем правиле нет мусора и оно легко читается.
IT>>В твоём правиле куча мусора, за которым не видно логики.
L>В твоём правиле куча мусора, за которым не видно ошибок.

Покажи мусор в коде с var, которого нет в коде с явным указанием типов.

L>Будем дальше продолжать в том же духе, или перейдем от голословных утверждений хоть к каким-то примерам?

С примерами у тебя пока туговато. Сначала ты приводишь теоретический пример, где проблема в каждой итерации и делаешь далеко идущие выводы. Потом в качестве практического подтверждения приводишь какой-то левый пример с баиндингом, где проблема уже не в каждой итерации. Мне как-то продолжать в таком ключе продолжать не очень интересно.

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

VD>На самом деле если мы не указываем типы внутри методов, то мы оперируем их более абстрактными интерфейсами. В эти интерфейсы входят только те методы, что были применены внутри тела метода.

Не находишь, что это напоминает шаблоны C++?

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

L>>И почему в таком случае не будет проблем после прокручивания внешнего enumerable-а? У стрима position будет на конце и дальнейшая работа с внешним enumerable-ом будет обламываться.

IT>Если будет обламываться, то это очень хорошо.

Двумя сообщениями выше было:

Мы не огнебём.

Я недоумевае.

IT>Тебе же вроде как не нравится нежелательное поведение, а не обломы.

Мне не нравится отсутствие возможности увидеть это из кода (в частности при ревью).

L>>Проблема возникает именно из-за ленивой природы линковских запросов. Использование var скрывает проблему. Не-использование выставляет ее напоказ.

IT>Такие скрытия в нашей жизни происходят постоянно.

И что из того? Это сразу нивелирвует проблему в ноль что-ли?

IT>Вот тебе, например, типичные скрытия:

IT>

IT>myObj.Foo().Bar();
IT>

IT>Какой тип возвращает Foo? Или ты тоже в таких случаях всегда заводишь локальную переменную, чтобы не дай бог не ошибиться?

Пример некорректен. Здесь не будет промежуточной переменной ни в товем ни в моем случае.

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

IT>>>В твоём правиле куча мусора, за которым не видно логики.
L>>В твоём правиле куча мусора, за которым не видно ошибок.

IT>Покажи мусор в коде с var, которого нет в коде с явным указанием типов.

Покажи мусор в коде без var.

L>>Будем дальше продолжать в том же духе, или перейдем от голословных утверждений хоть к каким-то примерам?

IT>С примерами у тебя пока туговато. Сначала ты приводишь теоретический пример, где проблема в каждой итерации и делаешь далеко идущие выводы. Потом в качестве практического подтверждения приводишь какой-то левый пример с баиндингом, где проблема уже не в каждой итерации.

Да, с примерами у меня огромная проблема. Зато у вас с ними все хорошо — нет примеров, нет проблемы.

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

WH>>Ибо защиту и скорость обеспечивает вывод типов, а документирование нормальные имена переменных.
I>Какую защиту обеспечит вывод типов от ошибки, когда непреднамеренно используется метод отсутствующий в ICollection?

Что значит непреднамеренно?

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

T>>>Нет, в diff-тулах от системы контроля версий. Что показательно даже у TFS там нет никакого интеллисенса, подсказок и навигации по коду.
IT>>Круто. Но на бумаге было бы круче.
L>Интересно было бы услышать как ты предлагаешь делать ревью.

Для начала следует определиться понимаем ли мы одно и тоже под термином code review.

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

IT>>Вот тебе, например, типичные скрытия:

IT>>

IT>>myObj.Foo().Bar();
IT>>

IT>>Какой тип возвращает Foo? Или ты тоже в таких случаях всегда заводишь локальную переменную, чтобы не дай бог не ошибиться?

L>Пример некорректен. Здесь не будет промежуточной переменной ни в товем ни в моем случае.

Здесь будет таже проблема, о которой ты говоришь.

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

IT>>>Круто. Но на бумаге было бы круче.
L>>Интересно было бы услышать как ты предлагаешь делать ревью.

IT>Для начала следует определиться понимаем ли мы одно и тоже под термином code review.

Во всех командах, где мне доводилось работать, под "code review" понималась регулярная проверка кода, измененного за определенный промежуток времени. Для этого тех. лид просматривал дифы, внесенные его коллегами за последние день-два-три.

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

IT>>Покажи мусор в коде с var, которого нет в коде с явным указанием типов.
L>Покажи мусор в коде без var.

IEnumerable<Customer> customers = GetCustomers();
^^^^^^^^^^^^^^^^^^^^^ <- мусор здесь

IT>>С примерами у тебя пока туговато. Сначала ты приводишь теоретический пример, где проблема в каждой итерации и делаешь далеко идущие выводы. Потом в качестве практического подтверждения приводишь какой-то левый пример с баиндингом, где проблема уже не в каждой итерации.

L>Да, с примерами у меня огромная проблема. Зато у вас с ними все хорошо — нет примеров, нет проблемы.

У тебя проблема не только с примерами, но ещё и с памятью.

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

L>>Пример некорректен. Здесь не будет промежуточной переменной ни в товем ни в моем случае.

IT>Здесь будет таже проблема, о которой ты говоришь.

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

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

IT>Что значит непреднамеренно?

Unattended.

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

IT>>>Покажи мусор в коде с var, которого нет в коде с явным указанием типов.
L>>Покажи мусор в коде без var.

IT>

IT>IEnumerable<Customer> customers = GetCustomers();
IT>^^^^^^^^^^^^^^^^^^^^^ <- мусор здесь
IT>

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

L>>Да, с примерами у меня огромная проблема. Зато у вас с ними все хорошо — нет примеров, нет проблемы.

IT>У тебя проблема не только с примерами, но ещё и с памятью.

Да, старею. совсем плохой стал.
Тебя не затруднит мне немощному еще раз привести тот мега-пример, который ты якобы приводил? Ну пожалуйтса.

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

VD>>На самом деле если мы не указываем типы внутри методов, то мы оперируем их более абстрактными интерфейсами. В эти интерфейсы входят только те методы, что были применены внутри тела метода.

I>Не находишь, что это напоминает шаблоны C++?

Нет.

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

VD>Нет.

В чем же две большие разницы? Твое "если мы не указываем типы внутри методов, то мы оперируем их более абстрактными интерфейсами. В эти интерфейсы входят только те методы, что были применены внутри тела метода" вполне относится и к шаблонам функций C++:

template <class T>
void f(T const& t)
{
    // оперируем "более абстрактным интерфейсам" t,
    //   в который входят только те функции,
    //     что были применены внутри f
}

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

I>Ну вот ты пишешь код работающий только с ICollection
Что это за задача такая что нужно писать код работающий только с ICollection?

I>и создаешь эту самую ICollection как new Dictionary. Затем случайно используешь метод имеющийся в Dictionary, но отсутствующий в ICollection. В зависимости от того, объявишь ли ты переменную как ICollection или как Dictionary, компилятор схватит тебя за руку или нет. Во втором случае сопровождающий программу возможно получит ненужную проблему, когда несколькими годами позже попытается заменить Dictionary на что-нибудь другое.
Слишком много если чтобы об этом думать.
В любом случае замена словаря на что-то другое это само по себе не слабое изменение алгоритма.
А менять алгоритм не включая мозг это само по себе глупо.

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

I>Ну вот ты пишешь код работающий только с ICollection и создаешь эту самую ICollection как new Dictionary. Затем случайно используешь метод имеющийся в Dictionary, но отсутствующий в ICollection. В зависимости от того, объявишь ли ты переменную как ICollection или как Dictionary, компилятор схватит тебя за руку или нет. Во втором случае сопровождающий программу возможно получит ненужную проблему, когда несколькими годами позже попытается заменить Dictionary на что-нибудь другое.

У тебя извращенная (перевернутая) логика. Я пишу код реализующий алгоритм, а не "код работающий только с ICollection".

Ограничения на тип коллекции обычно накладываются неким публичным интерфейсом или неким полем в некой структуре. Но тогда компилятор сам остановит тебя от использования более широкого типа.

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

WH>Что это за задача такая что нужно писать код работающий только с ICollection?

Хрен ее знает, тебе конкретика нужна? Посмотри примеры в MSDN, где сплошь и рядом создаваемый FileStream присваивается переменной того же типа, хотя переменная эта вполне могла бы иметь тип Stream.

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

IT>>

IT>>IEnumerable<Customer> customers = GetCustomers();
IT>>^^^^^^^^^^^^^^^^^^^^^ <- мусор здесь
IT>>

L>Это не мусор, это аннотация типа, которая часто при ревью позволяет увидеть потенциальные проблемы.

Если проблема видна только с аннотациями тиов локальных переменных, то код является помойкой и ждать что-то хорошее от него я бы не стал.

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

WH>>Что это за задача такая что нужно писать код работающий только с ICollection?
I>Хрен ее знает, тебе конкретика нужна? Посмотри примеры в MSDN, где сплошь и рядом создаваемый FileStream присваивается переменной того же типа, хотя переменная эта вполне могла бы иметь тип Stream.
А в чем проблема то?
Какая разница какие типы используются внутри метода?