How to become an author
Search
Write a publication
Pull to refresh

Comments 119

Linq тут, в общем то, ни при чём, это специфика IEnumerable\IEnumerator.
Осмелюсь предположить, что заминусуют за низкий технический уровень

Total votes 10: ↑9 and ↓1+8

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

Total votes 14: ↑13 and ↓1+12
UFO just landed and posted this here
.Select(x=>new Entity(x.id))

это абсолютно нормально
вызовы несколько раз First и удивление девелопера почему два результата first не равны по ссылке

а вот это нет)
Total votes 3: ↑3 and ↓0+3
Познавательно, конечно, спасибо, но если бы меня такое спросили, я бы ответил, что лучше такой код переписать. Ведь что у нас по сути? Во-первых, предикат с побочным эффектом. Во-вторых, лямбда с императивным кодом. И всё это одна сущность!
Total votes 11: ↑10 and ↓1+9
Тут учебный пример, чтобы посчитать, сколько раз вызывается оператор сравнения.
Total votes 6: ↑5 and ↓1+4

Резюмируя:

  1. Метод Where (и многие другие методы-расширения IEnumerable) - ленивый, он строит всего лишь объект, состоящий из пары: исходная последовательность и предикат. Больше ничего он не делает. Построенный объект при своем итерировании будет заставлять итерироваться внуренний и проверять предикат.

  2. Метод First в силу своей специфики будет итерировать последовательность (а значит и исходную) до первого элемента - а для исходной до первого выполнения условия. это 3 итерации.

  3. Метод Last - будет итерировать всю псоледовательность (ну и соответственно исходную тоже) - это 5 итераций.

  4. Для каждого получения представления результата Where будет проитерирована вся исходная последовательсть - отсюда инкременты равные 5.

    Ничего не упустил?

Total votes 13: ↑12 and ↓1+11

Метод Last в .NET Core и .NET 5 может не перебирать всю коллекцию, а взять сразу последний элемент.

Total votes 1: ↑0 and ↓1-1

Если это коллекция. В данном случае не может.

This comment wasn’t rated yet0

Зачем обсуждать в статьях какой именно будет побочный эффект неправильного кода?

Total votes 11: ↑7 and ↓4+3
Это просто формализация задачи.
Вопрос мог быть задан так: сколько раз выполнится проверка неравенства (x>0) в коде
var array = new[] { 0, 0, 1, 0, 1 };
var bytes = array.Where(x => x > 0);
bool t = bytes.First() == bytes.Last();

К такой постановке вопроса есть претензии?
Total votes 8: ↑6 and ↓2+4

Есть: "а зачем вы спрашиваете?".


Есть простая мнемоника: никогда не делайте multiple enumeration по enumerable. Она этот вопрос снимает полностью.

Total votes 17: ↑12 and ↓5+7

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

Total votes 8: ↑4 and ↓40
С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца

Нет, нельзя этого ожидать. Enumerable двигается только вперед.

Total votes 8: ↑7 and ↓1+6

Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".

Total votes 2: ↑2 and ↓0+2

Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.

Total votes 3: ↑1 and ↓2-1

Я и не говорил, что она снимает все проблемы, я говорил, что она снимает вопрос в статье.

Total votes 3: ↑3 and ↓0+3
Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны.

Почему ошибочно-то? Надо исходить из того, что они эквивалентны, а все остальное — необязательная оптимизация.


И то, что несколько человек на этом попались, опровергает тезис "нельзя".

Неа, не опровергает. Оно лишь доказывает, что люди имеют какие-то ожидания. Правильные ли это ожидания — вопрос отдельный.

Total votes 3: ↑3 and ↓0+3

Собственно, данная статья и работает в пользу приведения ожиданий людей к реальности.

Total votes 2: ↑2 and ↓0+2

Учитывая, что там дофигилион оптимизаций...

Total votes 1: ↑1 and ↓0+1
… которые по-любому зарубаются использованием побочного эффекта в коде из статьи.

PS А по жизни, согласен с многими предыдущими комментаторами, такой код писать не надо. Но, к сожалению, читать временами приходится и такой код.
Total votes 2: ↑2 and ↓0+2

… про которые никогда не знаешь, какие у тебя будут в текущей версии.

Total votes 1: ↑1 and ↓0+1

Мир не ограничивается одним .NET, есть другие библиотеки с более эффективными аналогами Enumerable, поэтому ожидание «с единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца» у бегло просматривающиего код вполне ожидаемо (извиняюсь за тавтологию).

Total votes 2: ↑0 and ↓2-2
Мир не ограничивается одним .NET

В статье про .NET разумно ожидать, что будет рассматриваться поведение .NET.

Total votes 5: ↑5 and ↓0+5

Безусловно.

Но:

  1. Пиша на .NET, неразумно писать так, как будто каждый читающий код на 100% знает всю подноготную .NET. Чем интуитивнее код — тем лучше.

  2. Читая статью про подноготную .NET, неразумно автоматически предполагать, что она написана для людей, на 100% знающих подноготную .NET. Таким людям эта статья просто не нужна.

Total votes 2: ↑2 and ↓0+2
Пиша на .NET, неразумно писать так, как будто каждый читающий код на 100% знает всю подноготную .NET. Чем интуитивнее код — тем лучше.

… и как же вы предлагаете сделать "интуитивнее" в случае кода в статье?

Total votes 3: ↑3 and ↓0+3

Расскажите, как найти последний элемент перечисления, не перебирая его?

Не массива, не списка или коллекции, а именно перечисления

На всякий случай, вот Вам интерфейс ienumerator

MoveNext возвращает true, если есть следующий элемент и пишет его в Current.

Current возвращает текущий элемент

Total votes 4: ↑4 and ↓0+4

Ну я ж сказал, не лист и не массив, а перечисление

Total votes 3: ↑2 and ↓1+1
Зачем вы настаиваете на перечислении, если в примере конкретно массив. И библиотеки могут оптимизироваться под тип коллекции, а могут и не оптимизироваться.
Total votes 1: ↑1 and ↓0+1

Потому что изначально я отреагировал на вот это "есть другие библиотеки с более эффективными аналогами Enumerable"

Более того, сам .net имеет оптимизации для листов и не только для кейса Last, но и для других.
А тут, видимо, предлагается ввести целую иерархию новых интерфейсов

Total votes 2: ↑2 and ↓0+2
Есть: «а зачем вы спрашиваете?».
Вопрос на понимание, что происходит под капотом.
Есть простая мнемоника: никогда не делайте multiple enumeration по enumerable. Она этот вопрос снимает полностью.
Вы слишком категоричны. Наверняка можно придумать сценарии, в которых повторные проходы по фильтрованному enumerable дешевле, чем например копирование его в List.
Total votes 7: ↑7 and ↓0+7
Вопрос на понимание, что происходит под капотом.

Понимаю: двойное перечисление, которого надо избегать. Сколько при этом будет вызовов лямбды — вопрос неочевидный, и зависит от имплементации.


Наверняка можно придумать сценарии, в которых повторные проходы по фильтрованному enumerable дешевле, чем например копирование его в List.

Это если вы знаете, что ваш Enumerable не упадет от повторного прохода.


(понятно, что из правил есть исключения, но мнемоника на то и мнемоника, чтобы помогать в большинстве случаев)

Total votes 6: ↑6 and ↓0+6
Есть простая мнемоника: никогда не делайте multiple enumeration по enumerable.

А как вы применяете эту мнемонику к рассматриваемой задаче — уточнить можно?
Мне это непонятно. Потому как в этой задаче нет ситуации с созданием нескольких одновременно активных итераторов — той самой, которую описывает мнемоника и которая реально может вызвать проблемы, например, потому что повторный вызов GetEnumerable имеет право вернуть тот же самый итератор, что и при первом вызове.
В этой же задаче такого нет. Мы же все помним, что исполнение методов расширения First и Last для IEnumerable производится немедленно, отложенного исполнения для них не предусмотрено? А потому при вычислении первого из значений по сторонам равенства (не важно в каком порядке) итератор запрашивается, используется и освобождается, и только потом, при вычислении следующего значения, итератор запрашивается повторно, опять используется и освобождается. То есть — никакого multiple enumeration нет.

PS Безотносительно к вашему комментарию. Обращение к IEnumerable<T>.Current после возврата false из IEnumerable<T>.MoveNext мне не нравится: в документации по IEnumerable.Current были слова о том, что значение Current не определено, в документации по IEnumerable<T>.Current этих слов нет, но и обратного утверждения нет тоже.
This comment wasn’t rated yet0

Потому как в этой задаче нет ситуации с созданием нескольких одновременно активных итераторов — той самой, которую описывает мнемоника и которая реально может вызвать проблемы, например, потому что повторный вызов GetEnumerable имеет право вернуть тот же самый итератор, что и при первом вывызове.М

Мнемоника совсем не об одновременно активных итераторах. Вообще, если GetEnumerator возвращает тот же самый итератор, а не каждый раз новый - это плохой итератор, именно для этого разделены интерфейсы IEnumerable и IEnumerator.

А мнемоника как раз о том, что enumerator может лезть в БД или отправлять запросы и делать кучу чего тяжёлого и лучше, без необходимости, этого не делать. Тут ни слова о том, что Вы описали с одновременным использованием enumerator

Total votes 2: ↑2 and ↓0+2
Потому как в этой задаче нет ситуации с созданием нескольких одновременно активных итераторов — той самой, которую описывает мнемоника

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


То есть — никакого multiple enumeration нет.

Как только вы вызвали GetEnumerator больше одного раза, случился multiple enumeration.

Total votes 4: ↑3 and ↓1+2
Я понял вашу позицию.
Total votes 2: ↑1 and ↓10

никогда не делайте multiple enumeration по enumerable

Копирование в общем случае может обходиться как дешевле, так и дороже повторного использования enumerable, так что Ваше «никогда» слишком категорично.

Total votes 3: ↑3 and ↓0+3

Задача мнемоники — покрывать большую часть случаев, а не все.


В общем случае повторное использование может быть просто невозможно.

Total votes 4: ↑4 and ↓0+4

Задача мнемоники — покрывать большую часть случаев, а не все.

А где об этом написано? Насколько я знаю:

  1. Задача мнемоники — упростить запоминание какого-то утверждения. При этом наличие у утверждения мнемоники совершенно не подразумевает каких-либо поблажек к точности утверждения. Т.е. иными словами мнемоника — лишь средство запоминание, а не характеристика точности/правильности утверждения.

  2. Разве Ваша фраза вообще мнемоника?

В общем случае повторное использование может быть просто невозможно.

Ок, уточню: в общем случае использования интерфейса, который позволяет повторное использование. Да, технически в .NET нету отдельных IEnumerableOnce и IRobustEnumerable, но логически-то это всё равно разные вещи. И во многих случаях мы знаем, какой именно «подвид» IEnumerable тут гарантирован.

Total votes 1: ↑1 and ↓0+1
А где об этом написано?

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


в общем случае использования интерфейса, который позволяет повторное использование

Если передо мной неизвестный IEnumerable, для меня безопаснее считать, что он не позволяет повторное использование, чем наоброт.


И во многих случаях мы знаем, какой именно «подвид» IEnumerable тут гарантирован.

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

Total votes 3: ↑2 and ↓1+1
Вообще я думал, что ответ будет 4, т.к. Last должен идти от конца массива, пока не встретит подходящий элемент. Но оказывается, текущая реализация в .NET не такая умная.
Хотя вот здесь получается именно 4:
bool t = 
        array.First(x => { linqCounter++; return x > 0; })
         == array.Last(x => { linqCounter++; return x > 0; });
Total votes 3: ↑1 and ↓2-1
Вообще я думал, что ответ будет 4, т.к. Last должен идти от конца массива, пока не встретит подходящий элемент.

После Where LINQ уже не знает, массив там или нет.

Total votes 12: ↑12 and ↓0+12
Это сейчас не знает, а завтра сделают оптимизацию, и Where вернёт не IEnumerable, а IQueryable, и тогда Last сможет искать с конца.
Total votes 1: ↑1 and ↓0+1

Проблема "завтра сделают оптимизацию" в том, что могут сделать, а могут не сделать, а могут сделать не так, как ожидается. Держать это все в голове обычно не выгодно, проще профилировать конкретные узкие места.

Total votes 5: ↑5 and ↓0+5
Значит, ваше утверждение в общем случае неверно
После Where LINQ уже не знает, массив там или нет.
Total votes 2: ↑1 and ↓10

У нас с вами, видимо, разное понимание "общего случая".

Total votes 5: ↑5 and ↓0+5
Я это понимаю так, что в текущей версии .NET (предположительно) «После Where LINQ уже не знает, массив там или нет», а будущих версиях можно сделать, чтобы знал и оптимизировал (я ниже написал, как).

То есть, общий случай — это некая произвольная версия .NET
This comment wasn’t rated yet0

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

Total votes 3: ↑3 and ↓0+3
Чуть выше вы ссылаетесь на некие общие соображения («зависит от реализации»), то есть вам было лень разбирать конкретную версию. А сейчас вы отстаиваете точку зрения, что в неопределённых спецификацией моментах надо ориентироваться на конкретную версию. Как удобно…
Total votes 2: ↑1 and ↓10
А сейчас вы отстаиваете точку зрения, что в неопределённых спецификацией моментах надо ориентироваться на конкретную версию.

Эээ, я не отстаиваю эту точку зрения. Я как раз считаю, что нужно ориентироваться на описанное поведение (т.е. обычный для enumerable перебор), которое не специфично для версии.

Total votes 4: ↑4 and ↓0+4
Даже можно не уходить на IQueryable, а остаться на IEnumerable. Сделать специализацию для Where для IList, которая вернёт ListEnumerable: IEnumerable, и сделать специализацию для Last, которая для ListEnumerable будет перекрывать реализацию произвольного IEnumerable.
Total votes 2: ↑1 and ↓10

Мммм, вы представляете себе количество труда для такой "специализации"?


(иными словами, как вы думаете, почему оптимизация для Count делает проверки на ICollection внутри?)

Total votes 1: ↑1 and ↓0+1
Это не снимает моего возражения против ваших утверждений что «После Where LINQ уже не знает». Можно так же генерировать ListEnumerable для источника IList, но проверять на него не в compile-time, а в run-rime.
Total votes 4: ↑2 and ↓20

На самом деле, не очень много. Все нужные оптимизации уже есть в методе Last(predicate), осталось только научиться автоматически сокращать Where(predicate).Last() до более оптимальной формы.

This comment wasn’t rated yet0
осталось только научиться автоматически сокращать Where(predicate).Last() до более оптимальной формы.

… всего ничего, да.


Впрочем, дело не в этом даже. Дело — для меня — в том, что никогда не знаешь, где уже пора остановиться. Вот мы оптимизировали Where().Last(). А Select().Last() надо оптимизировать? А Where().Select().Last()? А Skip().Select().Last()?

Total votes 2: ↑1 and ↓10

Не сделают, посмотрите интерфейсы IEnunerable и IEnumerator. First и Ladt объявлены именно для IEnumerable. Разная реализация через апкасты нарушит LSP. Не сказать, что IQueryable не нарушает LSP, но это был общий, а не частный случай и осознанный выбор, который оказался верным. Не говоря уже о бесконечных последовательностях.

Total votes 3: ↑0 and ↓3-3

Но там внутрях уже разная реализация через апкасты! Например, array.Count() не будет перечислять массив, а просто вернёт Length.


Кстати, реализация First и Last нарушать LSP не может в принципе, потому что LSP — требование к иерархии типов, а не к внешним операциям над ними.

Total votes 4: ↑4 and ↓0+4

Но там внутрях уже разная реализация через апкасты! Например, array.Count() не будет перечислять массив, а просто вернёт Length.

Пока вы не добавили предикат

Кстати, реализация First и Last нарушать LSP не может в принципе, потому что LSP — требование к иерархии типов, а не к внешним операциям над ними.

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

Total votes 2: ↑0 and ↓2-2

А почему, собственно, он не работает с другим? Работает, но по-другому.


Вы бы вместо теории посмотрели как там на самом деле всё реализовано:


https://github.com/dotnet/runtime/blob/main/src/libraries/System.Linq/src/System/Linq/Last.cs#L64


Как видно, там уже есть отдельные ветки для списков и для внутреннего интерфейса IPartition<T>. И вполне возможна ситуация, что семейство классов WhereFooIterator<…> однажды тоже попадёт в этот список.


Собственно, вызов Last(predicate), который вроде как "эквивалентен" обсуждаемому Where(predicate).Last(), для массивов и прочих списков уже работает "с конца"!

Total votes 5: ↑4 and ↓1+3

Что меня в этом коде расстраивает — так это то, что можно внезапно больно удариться.


Вот был у нас класс, не знаю, Recordset, и реализовывал он IEnumerable<Record>. Все было хорошо, ходил в БД, отдавал данные, блаблабла.


А потом один программист взял и добавил к этому интерфейсу IList<Record>. И все бы ничего, но… начали течь ресурсы.


Как так?

Total votes 2: ↑2 and ↓0+2

Именно в этом коде вот так удариться можно? Что-то не верится.


Больше походе, что проблема в самом добавлении IList<Record>, как-то не вяжется этот интерфейс с кодом, который непосредственно ходит в базу.

Total votes 2: ↑1 and ↓10
Именно в этом коде вот так удариться можно? Что-то не верится.

Можно. Имплементаторы IPartition и IList не диспозятся, а стандартный энумератор — диспозится.


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

Total votes 1: ↑1 and ↓0+1

Но ведь они в этом методе и не создаются, в отличии от энумератора.


Общее правило — кто создавал, тот и диспозит, если не оговорено обратное — соблюдается. Так откуда неожиданности?

Total votes 3: ↑2 and ↓1+1

Я же говорю, я понимаю, по какой логике там действовали.


Однако люди, которые запихнули закрытие коннекшна к БД в Dispose от итератора, тоже вполне себе руководствовались понятной (и существующей) логикой. И оно вполне себе работало… а теперь сломалось.

Total votes 2: ↑1 and ↓10

Э-э-э, а что бы эти люди делали при множественных итерациях, которые вроде и должны избегаться — но всё ещё разрешены?


Если соединение закрывается в Dispose — значит, оно должно открываться в GetEnumerator и только там. Все остальные способы дают на выходе хрупкий код, и нечего тут на библиотеку пенять когда сами ерунду по-написали.

Total votes 5: ↑4 and ↓1+3
Э-э-э, а что бы эти люди делали при множественных итерациях, которые вроде и должны избегаться — но всё ещё разрешены?

А ничего. Не разрешены у пользователей (этого кода) множественные итерации.


(это, в отличие от добавления IList, не вымышленный дизайн)

Total votes 2: ↑2 and ↓0+2

Да, про Last без Where загнался, вы правы. Я имел в виду именно вариант, когда предикат записан отдельным Where, чтобы на выходе IEnumerable был

.Where(predicate).Last();

Я по этому поводу согласен с @lair, что можно словить нежданчик. Может имело смысл сделать отдельную перегрузку для IList, чтобы такие вещи были более явными.

This comment wasn’t rated yet0

Оно не может идти от конца массива, т.к. оперирует IEnumerable, а для него чтобы узнать, где конец - надо попробовать все. Иногда конца даже может не быть ((

Total votes 6: ↑5 and ↓1+4

Замените var на точный тип, и узнаете много нового :)

Total votes 1: ↑1 and ↓0+1

В подавляющем большинстве случаев, надо знать куда смотреть. Если не знаешь, то явное указание типов не поможет.

This comment wasn’t rated yet0

"Можете ли вы уверенно сказать, что будет выведено на консоль в результате выполнения следующего кода?"

да

Total votes 13: ↑12 and ↓1+11

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

Total votes 2: ↑1 and ↓10
Ну вот зачем захватывать что-то в лябмду?

По жизни — чтобы снизить число параметров. С точки зрения теории — а как без захвата реализовать на C#, к примеру, каррирование?
Насчет очень редко… Не знаю, как вам, а команде, которая ASP.NET Core разрабатывала, это требовалось отнюдь не редко — в коде инициализации ASP.NET Core таких лямбд полно.

Что реально плохо в C# (с точки зрения использования функционального стиля, настоящим программистам это, наоборот, хорошо) — это то, что переменная захватывается по ссылке и это проиисходит AFAIK молча (не знаю, может есть опция включить на это предупреждение компилятора, но я такой не видел). В результате можно получить очень интересные и неожиданные изменения.
This comment wasn’t rated yet0

На сколько я помню, в asp.net все лямбды захватывают только immutable-переменные, поэтому поведения из статьи в asp.net не наблюдается. Поправьте, если не прав.

Total votes 2: ↑1 and ↓10
На сколько я помню, в asp.net все лямбды захватывают только immutable-переменные

Давайте сначала разберемся только: вы под immutable-переменной понимаете что? Скажем, вот такое — это захват mutable или immutable?


Action Foo(HttpContext ctx)
{
  return () => Bar(ctx);
}
Total votes 4: ↑4 and ↓0+4

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

Total votes 3: ↑2 and ↓1+1

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

Total votes 2: ↑1 and ↓10
UFO just landed and posted this here

Я не знаю, мне это прям регулярно нужно.

Total votes 5: ↑5 and ↓0+5

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

This comment wasn’t rated yet0

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

Total votes 4: ↑4 and ↓0+4

Можете ли вы уверенно сказать, что будет выведено на консоль

А когда предлог в заменили на на? Ведь всегда было "вывести в консоль" или "вывести на экран". Или это отголоски всяких "погуглить за программирование" и "вспомнил за канал"?

Total votes 10: ↑1 and ↓9-8
А когда предлог в заменили на на?

IMHO использование любого из этих предлогов никак не влияет на легкость восприятия статьи.
Total votes 7: ↑6 and ↓1+5

По правилам хорошего тона, о грамматических ошибках в статье принято писать автору в личку.

This comment wasn’t rated yet0

Это я делаю десятки раз в день. Но не о таких массовых ошибках.

Total votes 3: ↑1 and ↓2-1
А когда предлог в заменили на на?

Очень давно. Вот журнал «Физика» за декабрь 1982:



Вот журнал «Вычислительная техника социалистических стран» того же года:



Наоборот, «вывод в консоль» начался только в нашем веке.
Total votes 8: ↑8 and ↓0+8

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

P.S. Можно было сделать array.Where(...).ToArray() и тогда ответ бы был всегда 5, что в выводе, что в отладчике, но может в конкретном случае перечисление заранее не нужно.

Total votes 4: ↑3 and ↓1+2

А почему Вы решили, что автор не знал?

Статья же не для автора, а для читателей. А многие из читателей могли этого не знать (и ряд каментов это доказывает). Особенно новички, которые еще не углублялись в особенности отложенного исполнения при использовании LINQ.

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

Total votes 5: ↑4 and ↓1+3

Плохо, что новички не знают. Все есть в спеке. На крайняк это очень легко дебажится.

Total votes 3: ↑2 and ↓1+1

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

Total votes 1: ↑1 and ↓0+1

Мне было проще: когда я учил C# LINQ'а не было:) Поэтому, когда он появился, то прочитал release notes. Кажется, там про ленивую природу было много написано.

Total votes 3: ↑3 and ↓0+3
Или, все же, постепенно на собственном опыте и статьям из Интернета постигали все тонкости?

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


Впрочем, тут дело какое: пока сам десяток раз не врежешься в то, что какие-то вещи работают неинтуитивно (например, вернешь IEnumerable изнутри using, или, из более свежего, вернешь Task оттуда же), все равно не запомнишь. И "старшим товарищам", которые говорят, что не надо так делать, все равно не будешь верить. "Ну, у меня ж работает".

Total votes 4: ↑3 and ↓1+2

Разумеется! В том, что как-то нельзя делать, главное же не то, что нельзя делать, главное - почему это нельзя делать.

Данная статья это вполне объясняет, так что я вообще не понимаю десятки комментаторов, которые пишут: "Такой код заставят переписать", "Так писать нельзя" и т.п.

Total votes 1: ↑1 and ↓0+1

А статья где-то объясняет, чего и почему нельзя делать?


Мне показалось, статья только констатирует "у меня тут вот такой код".

Total votes 5: ↑3 and ↓2+1

Дочитал. Ничего кроме


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

не вижу.

Total votes 3: ↑1 and ↓2-1

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

А впрочем, бессмысленно кого-то в чем-то убеждать. Количество положительных оценок говорит о том, что такие статьи гораздо более востребованы, чем академические и "сильные технические", хоть в них и нет негативных комментариев.

Total votes 1: ↑1 and ↓0+1
Я же не сказал, прочитайте последний абзац, там и другие есть.

… ну так может вы цитату приведете?

Total votes 1: ↑0 and ↓1-1

Мне пол статьи в комментарий засунуть?

Total votes 1: ↑0 and ↓1-1

А, всё ясно, вы и мои комментарии тоже невнимательно читаете. Я же выше написал, что не столько важно, как нельзя, сколько важно, почему нельзя.

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

Total votes 4: ↑3 and ↓1+2

На всякий случай повторю свой вопрос выше по треду:


А статья где-то объясняет, чего и почему нельзя делать?

Есть разница между объяснением, что происходит, и объяснением, почему нельзя так делать. Статья второго не делает, и это ее недостаток.


Понимая это, читатель уже разберётся, где и как ему использовать LINQ.

… или не разберется. В этом и проблема.

Total votes 3: ↑2 and ↓1+1

Статья второго не делает, и это ее недостаток

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

Total votes 2: ↑1 and ↓10
Вместо того, чтобы просто написать это автору

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


А читателю полезнее сразу видеть реакцию "не надо так делать" (почему — тоже объяснено в комментах).

Total votes 1: ↑0 and ↓1-1

А где вы видите хоть один ответ автора в этой дискуссии?

This comment wasn’t rated yet0

Вот именно поэтому и не вижу смысла что-то ему писать.

Total votes 5: ↑2 and ↓3-1

Так вы определитесь, после чтения его ответов или потому что он ещё ничего не ответил?

This comment wasn’t rated yet0

Похоже, иронию надо было сразу выделять, иначе не понятно.


Окей, прямым текстом: я не вижу смысла ему что-то писать, потому что я не видел никакой его реакции на комментарии в статье.

Total votes 4: ↑1 and ↓3-2

Так ещё даже суток не прошло, он статью вчера вечером написал.

А теперь он и не напишет, просто чтобы не отхватить минусов, которых ему накидают при любом ответе.

Total votes 3: ↑3 and ↓0+3

Отличная статья, столько холивара на пустом месте я давно не видел)))

Total votes 12: ↑11 and ↓1+10

На хабре стало частым, бесячем явлением - коммент ради коммента или ради душноты)

This comment wasn’t rated yet0
Третьим буду )))
Total votes 1: ↑0 and ↓1-1

Предлагаю автору ещё заменить linq на plinq и в следующей статье раскрыть тайну, почему без interlocked там то 7, то 8, то 9. Если уж стрелять себе в ноги, то до конца:)

Total votes 2: ↑2 and ↓0+2

У Вас там в массиве сначала две 1, потом 1 и 2, но продолжаете писать о двух единицах.

Total votes 1: ↑1 and ↓0+1

Вся статья - лишь Lazy Evaluation IEnumerable. И больше не нужно ничего изобретать, это уже джун должен знать. Всегда на собесах подобное спрашивал, иначе человек в принципе не понимает, что такое IEnumerable.

This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr