LINQ & Except - .NET

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

_FR>>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#

IB>б) Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.

Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.

Вот например такой артефакт имеет право на существование или нет? Как он соотносится с тем, что по твоим словам "задумывалось"?

IB>a) Все эти методы используются в Linq2Objects.

Я говорил про конкретно один мой собственный метод. Как Linq2Objects может его использовать? Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?

IB>c) Это все часть дизайна языка, так как Linq2Objects — часть языка.

Какого именно языка? C#? или VB? Или даже F#? а может Boo? или именно в шарпе методом ForEach пользоваться нельзя, а, например, в C++\CLI это не "затрудняет чтение и понимание"?

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

Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?

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

Тут я не соглашусь, ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?

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

ВВ>>Это ты сам сейчас придумал.
S>Нет. Читать здесь.
S>Покажи мне применение ForEach, в котором нет побочных эффектов.

Я уже показал.

S>pure function без возвращаемого значения эквивалентна {}. Это знают даже падаваны, а уж настоящим джедаям это положено знать — иначе лайтсабер никто не даст.

ThrowIfCollectionIsEmpty — это чистая функция. И да, в идеальном случае она должна быть эквивалента {}, как ты выражаешься, в чем я не вижу никакой проблемы.

S>Можно в студию пример ленивого форича?

var x = list.ForEach(action, condition);

ВВ>>Даю хинт — никто не запрещает в чистых функциях генерировать исключения.
S>Это и будет побочным эффектом.

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

ВВ>>А вообще причем тут побочные эффекты и проч.? Не нравится использовать замыкания для побочных эффектов? А каллбеки вообще можно использовать? К чему суть спора сводится-то?
S>К тому, что некоторые люди не могут понять простую и короткую статью даже после многократного прочтения. Больше никакой сути в споре нету.

Некоторым людям функциональное программирование как-то очень сильно на мозги повлияло. О функциональном программировании речи не было вообще. И нет абсолютно никаких проблем в том, что создавать побочные эффекты через замыкания — на то они и *замыкания* мляха — и все, что тут постоянно говорится в ответ, это какие-то максималистские рассуждения по поводу липертовского "мне не нравится".
Свое мнение есть, товарищ? Или вся работа мысли сводится к тому, что повсюду "страшные" подобочные эффекты мерещатся?

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

ВВ>Я уже показал.
Не вижу.

S>>Можно в студию пример ленивого форича?

ВВ>

ВВ>var x = list.ForEach(action, condition);
ВВ>

Какого типа будет x? Какова семантика этого ForEach? Выполняется ли action до condition или после? Что ты собираешься делать с этим x? Что будет при вызове list.ForEach(action1, condition1).ForEach(action2, condition2) — кто будет вызываться вперёд, action1 или action2?
Ты делаешь всё более плохие предложения.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

_FR>Какое отношение этот вот метод
_FR>

_FR>  static class Sequence
_FR>  {
_FR>    public static void ForEach<TSource>(this IEnumerable<TSource> source, Action<TSource> action) {
_FR>      foreach(var item in source) {
_FR>        action(item);
_FR>      }//for
_FR>    }
_FR>  }
_FR>

_FR>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#

а) Linq2Objects и есть набор екстеншнов для IEnumerable.
б) IEnumerable выступает жертвой этого метода — см. первый аргумент
ц) к дизайну языка имеет отношение Эрик Липперт — путём непосредственного личного участия. Против того, чтобы вы стреляли себе в ногу такими методами, он не возражает. Он возражает против внедрения такого метода в стандартную библиотеку, в отрыве от которой язык рассматривать нельзя.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

_FR>Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
_FR>Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?
Конечно могут. Их специализированность — в том, что они Mutable. Базовая библиотека предлагает набор чистых операций над immutable объектами.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

_FR>>имеет к a) Linq2Objects б) IEnumerable ц) дизайну языка C#

S>а) Linq2Objects и есть набор екстеншнов для IEnumerable.

То есть правильно ли я понимаю, что в твоём видении, любой, даже user defined, метод-расширение для IEnumerable можно причислить к Linq2Objects?

S>б) IEnumerable выступает жертвой этого метода — см. первый аргумент

Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"? Или слова Ивана о том, "что вся работа с последовательностями дизайнилась в функциональном стиле, а такой метод этот стиль нарушает."?

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

На сколько он отвечает всем выдвигаемым вами требованиям к методам-расширениям к "последовательностям"? И, если не отвечает, имеет ли он право на существование?

S>ц) к дизайну языка имеет отношение Эрик Липперт — путём непосредственного личного участия. Против того, чтобы вы стреляли себе в ногу такими методами, он не возражает. Он возражает против внедрения такого метода в стандартную библиотеку, в отрыве от которой язык рассматривать нельзя.

Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?

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

_FR>>Не все множества одинаковы. И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
_FR>>Или же, специализированные множества (List<>, Array) всё-таки могут иметь свои особые "операции" ForEach, RemoveAll и т.п.?
S>Конечно могут. Их специализированность — в том, что они Mutable. Базовая библиотека предлагает набор чистых операций над immutable объектами.

Надеюсь, Иван придерживается того же мнения

Потому что я хотел рассмотреть это вот его утверждение:

2. Выразительности такой код не добавит, а наоборот, запутает и, плюс к этому, "добавляет семантику замыкания, потенциально внося тонкие изменения в жизненные циклы объектов." То есть, реально, такой метод ухудшает имеющийся оператор foreach, добавляя малопредсказуемые побочные эффекты.

Не кажется ли вам (обоим), что применительно к Array.ForEach и List<>.ForEach этот аргумент так же можно применить? Какой выразительности добавляет, например, Array.ForEach, которой не будет у IEnumerable.ForEach, При этом, обращаю специальное внимание, мы читаем код, в котором типы вовсе могут быть не указаны:

var items = GetItems();
items.ForEach(DoSmth);

Почему это, в случае когда GetItems(); возвращает Array или List<> данный код лишён указанных Эриком и Иваном недостатков, а вот когда тип возвращаемого значения IEnumerable — они, недостатки, начинают мешать и дизайну и чтению?

Между прочим, а для IList<> и ICollection<> будут ли уместны расширения ForEach<>, раз уж расширение для List<> уместно?

Собственно, я понял бы точку зрения Ивана, если бы он ответил на мой вопрос, сказав, что метод ForEach вообще не применим не под каким соусом, ибо

plain foreach — чище, очевиднее и понятнее любого метода с Action<T> в качестве аргумента, я не понимаю, какие тут вообще могут быть сомнения..

+
Пресловутые сложности в отладке, которые так же упомянул Эрик — разве они исчезают для Array и List<>.

А вот твою точку зрения я ещё не до конца понимаю

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

_FR>То есть правильно ли я понимаю, что в твоём видении, любой, даже user defined, метод-расширение для IEnumerable можно причислить к Linq2Objects?
В принципе — да. Потому, что с точки зрения применения, они ничуть не отличаются. Мы всё еще помним о том, что код редко пишется и часто читается?
Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where? Весь опыт применения стандартных екстеншнов учит его, что они ленивы и безопасны.
_FR>Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"?
это тот аргумент, который помечен this

_FR>Между прочим, не могу не заметить, что вы упорно не отвечаете на вопрос о месте трюка, на который ты сам дал ссылку

Оппа. Что-то где-то глюкает — у меня уже пара ответов обрезалась. По поводу этого трюка поясняю следующее:
Он намеренно вводит семантику побочных эффектов в изначально чистую структуру — для того, чтобы сторонний наблюдатель мог разобраться, в какую императивную программу превращается декларативное описание. Заметь, что Барт не предлагает использовать это в боевых проектах — это отладка.

_FR>Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?
Конечно могу. Если у нас есть язык, в котором нет встроенного foreach, то метод ForEach был бы прекрасным его замещением. Точно так же, как и самопальные Using и Lock.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where? Весь опыт применения стандартных екстеншнов учит его, что они ленивы и безопасны.

На счёт — ленивы, это ты поторопился

Например, Count, тот же Aggregate или Except, даже Any и All не ленивы. Остаются вопросы безопастности. Теперь вспомним, что ForEach<> не имеет возвращаемого значения. Что может означать следующий вызов (если мы используем "опыт применения стандартных екстеншнов"):

// Какой-то код
items.ForEach(someParameter); // (1)
// Какой-то ещё код

Например некоторые языки не позволят случайно пропустить возвращаемое значение, и мы не будем рассматривать ситуацию, когда кто-то просто позвал

items.Where(someParameter);
items.Count(someParameter);

Как можно трактовать вызов (1), что бы не придти к выводу о том, что метод имеет "спецэффекты"?

Теперь рассмотрим такой код:

// Какой-то код
SomeMethod(items);
// Какой-то ещё код

Здесь ничего не ясно о том, имеет ли метод "спецэфекты", однако разве можно прожить без таких методов? Но, учтём и это для следующего:

Правильно ли (и на сколько точно?) тогда я сформулирую вашу мысль, сказав, что она заключается в следующем:

Не стоит иметь методы-расширения для IEnumerable, которые имеют "спецэффекты"

или, другими словами,

Методы, обрабатывающие последовательности IEnumerable со спецэффектами не должны быть методами-расширениями для IEnumerable

_FR>>Первый — это слова Эрика о том, что ему "не нравится метод для спецэфектов"?
S>это тот аргумент, который помечен this

_FR>>Между прочим, не могу не заметить, что вы упорно не отвечаете на вопрос о месте трюка, на который ты сам дал ссылку

S>Оппа. Что-то где-то глюкает — у меня уже пара ответов обрезалась. По поводу этого трюка поясняю следующее:
S>Он намеренно вводит семантику побочных эффектов в изначально чистую структуру — для того, чтобы сторонний наблюдатель мог разобраться, в какую императивную программу превращается декларативное описание. Заметь, что Барт не предлагает использовать это в боевых проектах — это отладка.

Ага, то есть отладка в боевом проекте — это не правильно?

В релизном коде этому не место — согласен, а "в боевом проекте" — почему нет? С соответствующими #ifdef и [Conditional].

Тогда сведём вопрос к следующему: может ли вообще существовать удобный и практичный метод-расширение для IEnumerable<>? Или его просто не следует делать расширением, ибо "Что должен думать читатель, напоровшись на строчку, в которой ForEach перемешан с Where?"?.

_FR>>Хорошо, тогда скажи, имеет ли хоть смысл держать такой метод в проекте ни C++/CLI? Boo и других языках, что существуют в платформе? Можешь ли ты предположить, что может существовать язык, в котором такой метод имело бы смысл иметь и где такой метод небыл бы "выстрелом себе в ногу"?
S>Конечно могу. Если у нас есть язык, в котором нет встроенного foreach, то метод ForEach был бы прекрасным его замещением. Точно так же, как и самопальные Using и Lock.

Отлично, тогда в стандартной библиотеке вполне может быть метод ForEach, поскольку стандартная библиотека общая на платформаму?

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

S>Какого типа будет x? Какова семантика этого ForEach? Выполняется ли action до condition или после? Что ты собираешься делать с этим x?

Для того, чтобы сделать ForEach ленивым достаточно просто превратить его в итератор. Кстати, в этом может быть даже смысл

Если мы хотим к примеру сделать действие пошаговым — выполнили действие, ждем подтверждения от пользователя, идти дальше или нет — как, к примеру, поиск в текстовом редакторе с кнопочкой Next. А если пользователь нажмет кнопочку Close, то нам и по всей последовательности пробегаться не придется.

Так что все просто. Обычный ForEach:

static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
{
    foreach (var i in self)
        if (condition(i))
            action(i);
}

Ленивый ForEach:

static IEnumerable<Int32> ForEach(this IEnumerable<Int32> self, Func<Int32,Boolean> cond, Action<Int32> act)
{
  foreach (var i in self)
     if (condition(i))
     {
       action(i);
       yield return i;
     }
}

S>Что будет при вызове list.ForEach(action1, condition1).ForEach(action2, condition2) — кто будет вызываться вперёд, action1 или action2?

А это ты уже сам проверь

var it = arr.ForEach(i => i < 2, Console.WriteLine).ForEach(i => i < 3, Console.WriteLine);

Кстати, раз уж зашел такой разговор, объясни мне теперь как ты себе представляешь себе ленивой функцию:

T Aggregate<T>(this IEnumerable<T> self, Func<T,T,T> func);

Очень интересно будет послушать

S>Ты делаешь всё более плохие предложения.

Согласен

Суть-то конечно не в том, чтобы ForEach превращать в ленивую чистую и светлую функцию. Ленивая — ну может иногда это имеет смысл. Чистая — ну может практически никогда

Ну и что с того? Вот вернемся к Aggregate. У меня половина использований этой ф-ции может иметь побочные эффекты. А знаешь почему? Потому что 1) агрегаты сложные, может быть несколько аккумуляторов, сложное состояние 2) побочные эффекты с замыканиями получить легко и удобно, ага. Потому что лямбды при всей своей как бы "функциональности" на самом деле деле таят в себе грубую и жестокую императивщину — независимо от того, из одного ли или нескольких экспрешионов они состоят. Ну например:

int y = 0;            
Func<Int32,Int32> f = x => y += x;

Ведь не убрали же "тонкую семантику замыкания" из лямбд почему-то. А это значит, что любая функция, принимающая замыкания, потенциально может иметь побочные эффекты. Тчк. И ForEach тут не исключение. Он просто... ну "чуть больше" склоняет нас к тому, чтобы сотворить побочные эффекты, чем тот же Aggregate.

Но это даже и неважно. Пусть ForEach у нас целиком "побочный" и неленивый. Ты объясни мне, что в этой функции такого, что надо с пеной у рта и кулаками доказывать, что она не нужна, вносит там всякое непонятно что и вообще зло в чистом виде, а? Липерт, которого ты переводил, написал, повторюсь:

1. В библиотеке System.Core этой функции нет и нечего ей там делать (с чем я абсолютно согласен).
2. Ему лично *с философской точки зрения* эта функция не нравится, но если вам нравится — напишите ее сами.

Все. После этого некоторые товарищи решили это самое "философское не нравится" превратить в какую-то догму. А нафига? Мнение Липерта закон? Странно вот получается, на Фаулера с Эвансом вам насрать, а Липерт — уже икона.

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

_FR>Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.
Ты о чем?

_FR>Вот например такой артефакт имеет право на существование или нет? Как он соотносится с тем, что по твоим словам "задумывалось"?
Тебе на это Синклер уже ответил.

_FR>Я говорил про конкретно один мой собственный метод.
Я про него же.

_FR> Как Linq2Objects может его использовать?
Ему не обязательно его использовать, важно, что он определяет культуру и стиль работы с коллекциями.
Ты, безусловно можешь это нарушить, в своих библиотеках и приложениях, но с моей точки зрения — это кривизна с четко видимым радиусом.

_FR>Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?
Это расширение языка для построения декларативных запросов к объектам реализующим IEnumerable.

_FR>Какого именно языка?
В данном случае (для простоты) C#, так как речь идет именно о нем. Другие, в данном контексте, меня не интересуют.

_FR> И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
Никто не призывает тебя ограничивать — расширяй сколько угодно, но не нарушай привычную семантику. Или расширяй другим образом. Например, против метода FredsLibrary.ForEach<T>(IEnumerable<T> source, Action<T> action) — никто не возражает.

_FR>Тут я не соглашусь,
Твое право.

_FR>ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?
Вот именно, и поэтому для твоей семантики место в другом месте, уж прости за тафталогию. Это же место, зарезервировано за операторами без побочных эффектов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

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

А>так всетаки дело в том, что он метод ForEach расширяющий?
Именно, Василий.. =)

А>ок, чем плох тот же самый метод но в виде простой статической функции?
Ну, например тем, что он совершенно бесполезен, и опять-таки ясности коду не добавит, если он имеет ту же семантику обычного foreach. Скажем, против метода Parallel.ForEach<T> — вообще никаких возражений нет — сразу видно, что это ни разу не обычный foreach, со своей логикой, которая, к тому же, очевидна из названия класса.
Почему-то им не пришло в голову делать extension method ParallelForEach<T>(this IEnumerable...)

А>почему все кто "читал липерта" навязывают оператор foreach?
С чего ты взял, что кто-то чего-то навязывает?

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

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

А>>так всетаки дело в том, что он метод ForEach расширяющий?
IB>Именно, Василий.. =)

[offtopic]
Мне вот интересно, а на основе каких умозаключений, ты делаешь вывод, что Аноним — это я? Может, я тогда и остальную твою логику пойму

Под анонимом заходят, чтобы написать:
1. Глупость
2. Хамство
3. Высказать свое мнение "несмотря ни на что", даже если оно противоречит "политике партии".
Я все это делаю под своим ником, зачем мне еще Аноним?

[/offtopic]

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

_FR>>Все имеющиеся — да сколько угодно. На счёт всех остальных — не понятно для чего.
IB>Ты о чем?

Все Extension methods для IEnumerable задумывались, как не имеющие побочных эффектов.

Странно, что "Все Extension methods для IEnumerable", даже те, которые я сам собираюсь написать, кем-то уже "задумывались"

_FR>> Как Linq2Objects может его использовать?
IB>Ему не обязательно его использовать, важно, что он определяет культуру и стиль работы с коллекциями.
IB>Ты, безусловно можешь это нарушить, в своих библиотеках и приложениях, но с моей точки зрения — это кривизна с четко видимым радиусом.

Я пытаюсь определить величину этого радиуса. Что "есть кривизна"? Правильно ли я её вывел здесь? Или нет?

_FR>>Можешь ли ты дать определение того, что является "Linq2Objects" что бы мы могли удостовериться, что говорим об одном и том же?
IB>Это расширение языка для построения декларативных запросов к объектам реализующим IEnumerable.

С точки зрения языка C# является ли метод Count() или Any() "Linq2Objects" или нет? Если следовать твоему определению, то нет. Тогда и ForEach() не имеет отношение к "Linq2Objects" так как не связан с "расширение языка для построения декларативных запросов…". Правильно?

_FR>>Какого именно языка?
IB>В данном случае (для простоты) C#, так как речь идет именно о нем. Другие, в данном контексте, меня не интересуют.

Хорошо, давай тогда разделим вопрос: о необходимости метода ForEach() в стандартной библиотеке и практике его использования в C#. От ответа на первую часть ты, я так понимаю, хотел бы уклониться, потому что тебя это не интересует? Хорошо, больше не буду на эту тему спрашивать, сосредоточусь на второй части.

_FR>> И не смотря на это, почему стоит "операции с множествами" ограничивать лишь операциями над базовым, самым обобщённым представлением множеств?
IB>Никто не призывает тебя ограничивать — расширяй сколько угодно, но не нарушай привычную семантику. Или расширяй другим образом. Например, против метода FredsLibrary.ForEach<T>(IEnumerable<T> source, Action<T> action) — никто не возражает.

Ну а как-же это я или кто-другой мог понять из твоих слов здесь

Вот поэтому я и прошу лишь точнее сформулировать вас вашу же точку на данный вопрос.

_FR>>ибо семантика моего метода отлична от "всех остальных" (нету возвращаемого значения). С какой это стати операции, имеющие различные семантики нужно рассматривать вместе?
IB>Вот именно, и поэтому для твоей семантики место в другом месте, уж прости за тафталогию. Это же место, зарезервировано за операторами без побочных эффектов.

Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?

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

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

А>>так всетаки дело в том, что он метод ForEach расширяющий?
IB>Именно, Василий.. =)
я не Василий

, но ты можешь звать меня Хозяин (с большой буквы пожалуйста)

IB>Ну, например тем, что он совершенно бесполезен, и опять-таки ясности коду не добавит, если он имеет ту же семантику обычного foreach. Скажем, против метода Parallel.ForEach<T> — вообще никаких возражений нет — сразу видно, что это ни разу не обычный foreach, со своей логикой, которая, к тому же, очевидна из названия класса.

IB>Почему-то им не пришло в голову делать extension method ParallelForEach<T>(this IEnumerable...)
пример некорректен. потому что это принципиально другой foreach. именно поэтому он у них в своем статическом классе название которого отражает суть обработки.
семантика расширяющего метода кроме прочего заключается в видимости "собственного" ForEach у разных последовательностей, особая обработка которых может быть инкапсулированна в этом методе.

IB>С чего ты взял, что кто-то чего-то навязывает?
читай ветку внимательно

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

_FR>Странно, что "Все Extension methods для IEnumerable", даже те, которые я сам собираюсь написать, кем-то уже "задумывались"

Задумывались не методы, а идеология. Сам ты можешь писать что угодно, но то, что ты напишешь либо укладывается в принятый стиль, либо нет. Конкретно extension method ForEach для IEnumerable — не укладывается. Еще вопросы?

_FR>Я пытаюсь определить величину этого радиуса.
У меня есть ощущение, что ты прекрасно все понял, но так как у тебя уже есть свой ForEach и ты очень не хочешь от него отказываться, то тебе просто очень хочется до чего-нибудь докопаться.

_FR> Тогда и ForEach() не имеет отношение к "Linq2Objects" так как не связан с "расширение языка для построения декларативных запросов…". Правильно?
Нет, не правильно. Еще раз перечитай мой предыдущий пост, там где говорится о том, что L2O не обязательно должен использовать все методы расширения.

_FR>Хорошо, давай тогда разделим вопрос: о необходимости метода ForEach() в стандартной библиотеке и практике его использования в C#. От ответа на первую часть ты, я так понимаю, хотел бы уклониться, потому что тебя это не интересует?
Относительно метода ForEach в стандартной библиотеке и так никаких несогласных мнений нет, так что непонятно зачем ты тут его вообще вспомнил.

_FR>Ну а как-же это я или кто-другой мог понять из твоих слов здесь

А что там непонятного? Возражения возникли только у тебя и у Василия и то, ровно по тому, что вы ратуете конкретно за extension method, так что не надо теперь передергивать и ратовать за точность формулировок.

_FR>Вот поэтому я и прошу лишь точнее сформулировать вас вашу же точку на данный вопрос.
Точнее уже некуда и так все разжевали что могли.

_FR>Какое? Этим местом является метод-расширение для IEnumerable или что-то ещё?
Тебе в восьмой раз повторить?

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>

От:	IB	http://rsdn.ru
Дата:	23.06.09 11:25
Оценка:

От:	IB	http://rsdn.ru
Дата:	23.06.09 11:25
Оценка:

От:	IB	http://rsdn.ru
Дата:	23.06.09 11:38
Оценка:

	От:	Аноним
	Дата:	23.06.09 11:42
	Оценка:	+1

От:	_FRED_	@ViIvanov
Дата:	23.06.09 12:01
Оценка:	16 (1)

	От:	Воронков Василий
	Дата:	23.06.09 12:01
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	24.06.09 03:57
Оценка: