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

J>IEnumerable<Customer> ?

А откуда уверенность, что именно Customer, а не ICustomer, к примеру?

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

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

T>>Понятно, то есть другими словами, если нам надо делать code-review, то пускаем пулю в лоб. Так и запишем.

IT>А вы code review на бумаге делаете?

Нет, в diff-тулах от системы контроля версий. Что показательно даже у TFS там нет никакого интеллисенса, подсказок и навигации по коду.

Здравствуйте, samius, Вы писали:
...
S>Что линк это монады он неоднократно упоминал в лекциях по хаскелю. А нет ссылки на слайды? Правда я с Rx еще не знаком, только наслышан.

Select и SelectMany собственно и есть механизм построения монад + query syntax. я это и пытался сказать выше, просто не очень получилось))

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

A_S>Select и SelectMany собственно и есть механизм построения монад + query syntax. я это и пытался сказать выше, просто не очень получилось))

Если что, об этом целый опус у меня в блоге. Можно покритиковать, кстати!

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

T>Понятно, то есть другими словами, если нам надо делать code-review, то пускаем пулю в лоб. Так и запишем.

Я понимаю, вашу позицию, но как я писал выше, считаю что тип переменной должен быть без сомнений понятен из имени и контекста использования. Если Вы делаете Code Review и обнаруживаете, что понимание вызывает затруднение, то код просто не принимаете.
Как то так.

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

IB>Сегодня Эрик Мейер начал лекцию со слов "Do you understand LINQ?". очень в тему.. )
IB>Как же он жжет, напалмом просто!!!
IB>И таки да, он показал, что мы нифига не понимаем LINQ ))
А где можно посмотреть эту лекцию?

Чтобы не быть голословным приведу конкретный пример.
Получение углов Эйлера из кватерниона:

class Quaternion
{
    // ...
    public EulerAngles Angles
    {
        get
        {
            var zDirection = this.Rotate(new Vector3(0, 0, 1));    // Vector3, т.к. операция, это поворот вектора кватернионом
            var projectedZDirection = new Vector3(zDirection.X, 0, zDirection.Z);    // Vector3, очевидно

            if (projectedZDirection.Length > 0.0001)
            {
                var normalizedProjectedZDirection = projectedZDirection.Normalized;    // Vector3, т.к. нормализованный проецированный вектор
                var yaw = CalculateAngle(normalizedProjectedZDirection.Z, normalizedProjectedZDirection.X);    // float, т.к. Yaq это угол Эйлера.

                var rotationWithoutYaw = Quaternion.RotationY(-yaw) * this;    // Quaternion, т.к. произведение кватернионов, это кватернион
                var zDirectionWithoutYaw = rotationWithoutYaw.Rotate(new Vector3(0, 0, 1));    // И т.д.
                var pitch = CalculateAngle(zDirectionWithoutYaw.Z, -zDirectionWithoutYaw.Y);

                var xDirectionWithoutYaw = rotationWithoutYaw.Rotate(new Vector3(1, 0, 0));
                var roll = CalculateAngle(xDirectionWithoutYaw.X, xDirectionWithoutYaw.Y);

                return new EulerAngles(yaw, pitch, roll);
            }
            else
            {
                var pitch = zDirection.Y > 0 ? -90 : 90;

                var xDirection = this.Rotate(new Vector3(1, 0, 0));
                var normalizedProjectedXDirection = new Vector3(xDirection.X, 0, xDirection.Z).Normalized;
                var yaw = CalculateAngle(normalizedProjectedXDirection.X, normalizedProjectedXDirection.Z);

                var rotationWithoutYawPitch = Quaternion.RotationX(-pitch) * Quaternion.RotationY(-yaw) * this;
                var xDirectionWithoutYawPitch = rotationWithoutYawPitch.Rotate(new Vector3(1, 0, 0));
                var roll = CalculateAngle(xDirectionWithoutYawPitch.X, xDirectionWithoutYawPitch.Y);

                return new EulerAngles(yaw, pitch, roll);
            }
        }
    }
    // ...
}

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

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

L>>Что значит "стрим может оказаться обыкновенной строкой"? Ты говоришь о System.IO.Stream?

IT>Конвертируем байты, заталкиваем в MemoryStream.

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

L>>

L>>if (customers.Any()) {
L>>  grid.DataSource = customers;
L>>  grid.DataBind();
L>>} else {
L>>  // ....
L>>}
L>>

L>>В этом коде будет та же самая проблема, что я и писал, только в меньшем масштабе (1 лишний запрос в базу).

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

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

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

L>>Нет, в моем правиле нет мусора и оно легко читается.

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

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

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

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

D>Например

D>Dictionary<string, EntityData> nameToEntityData = new Dictionary<string, EntityData>();

Этот "например" — неправильный "например", надо так:

IDictionary<string, EntityData> nameToEntityData = new Dictionary<string, EntityData>();

Или так:

ICollection<KeyValuePair<string, EntityData>> nameToEntityData = new Dictionary<string, EntityData>();

Или так:

IEnumerable<KeyValuePair<string, EntityData>> nameToEntityData = new Dictionary<string, EntityData>();

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

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

I>В любом из трех случаев явно указано, какими методами пользуется дальнейший код для работы с переменной nameToEntityData

А зачем? Мне достаточно видеть то какие методы используются в реальном коде. А типы пускай выводит компилятор. У него это отлично получается.

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

VD>А зачем? Мне достаточно видеть то какие методы используются в реальном коде. А типы пускай выводит компилятор. У него это отлично получается.

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

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

I>Затем, что типы не только для эффективности, но и для защиты от некоторых ошибок и более точного документирования.
От указания типов локальных переменных никакого толку нет.
Ибо защиту и скорость обеспечивает вывод типов, а документирование нормальные имена переменных.
Это я тебе говорю как человек имеющий опыт работы с языком в котором вывод типов мягко говоря намного сильнее чем var.

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

WH>Ибо защиту и скорость обеспечивает вывод типов, а документирование нормальные имена переменных.

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

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

0>Вот тут я бы с тобой поспорил. Что происходит, при замене конструкций вида foreach на вызов функций linq2objects? Повышается уровень абстракции — ты не просто делаешь foreach, а применяешь к последовательности определенные преобразования, реализация которых скрыта. В чем профит? Появление Plinq дает ответ на этот вопрос.

Профит еще в тех же ленивых вычислениях, когда можно просто описать все действия, а сам LINQ уже выполнит только необходимое. Но все это не кажется чем-то уж крайне необходимым и полезным.

Оптимизация связанная с многопоточностью, обычно либо уровнем выше (например, пул потоков на сервере), либо на уровне качественного изменения алгоритмов, кеширования и т. п. Для качественной оптимизации, данных, которые получает LINQ, может и не хватить. Ну и в таком случае я предпочитаю критические участки писать на чистом С, где все под контролем.

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

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

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

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

I>Затем, что типы не только для эффективности, но и для защиты от некоторых ошибок и более точного документирования.

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

По факту код написанный в функциональном стиле, с минимумом деклараций типов, в итоге оказывается намного более простым в понимании, отладке и сопровождении.

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

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

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

WH>Если тип переменной ICollection то будет ошибка компиляции.
WH>Если тип более конкретный то я не вижу почему это проблема.
WH>Попробуй привести пример в котором эта проблема проявляется.

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

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

IT>>А вы code review на бумаге делаете?
T>Нет, в diff-тулах от системы контроля версий. Что показательно даже у TFS там нет никакого интеллисенса, подсказок и навигации по коду.

Круто. Но на бумаге было бы круче.

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

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

IT>Круто. Но на бумаге было бы круче.

Интересно было бы услышать как ты предлагаешь делать ревью.