Comments 42
Спасибо за статью, 2 момента:
1. "… после вчерашнего поста юзера..." вчерашнего?
2. Статья о Noda Time не так давно переводилась здесь: Что же всё-таки не так со структурой DateTime?
1. "… после вчерашнего поста юзера..." вчерашнего?
2. Статья о Noda Time не так давно переводилась здесь: Что же всё-таки не так со структурой DateTime?
+1
Преобразует последовательность в строку с разделителями (то что обычно приходится делать через нудный Aggregate).
Нет, я все понимаю, но чем
string.Join
не угодил?+4
Ооо, класс!
Особенно радуют Split, TakeEvery, Prepend, DistinctBy, Batch.
А вот с ForEach не очень понял, в чем отличие от стандартного линковского?
Особенно радуют Split, TakeEvery, Prepend, DistinctBy, Batch.
А вот с ForEach не очень понял, в чем отличие от стандартного линковского?
0
А вот с ForEach не очень понял, в чем отличие от стандартного линковского?
«Стандартного линковского» не существует.
+3
А я-то думал, что ForEach — метод расширения и всем коллекциям доступен. А оказывается только List'у. Эх. Еще одно грустное открытие. :-)
+1
Почему грустное то? Раз вы про это не знали, то значит и проблем с этим не было, а если возникнут — вы теперь в курсе, как это легко решить )
0
Мне кажется, наоборот — хорошо. «Когда в руке молоток — всё кажется гвоздём» — часто вижу когда в подобные ФорИчи втыкают несколько-строчные лямбды — Ну почему не воспользоваться нормальным человеческим foreach?
+5
в LINQ короче запись получается. И если глаз натренирован, код компактнее получается, незахламленный «правильной структурой языка».
0
Также он нарушает purity присущую всем LINQ методам расширениям, и гораздо хуже выражает intention изменения данных.
НУ и очевидно дублирует классический foreach.
Лучше бы и у листа не было.
НУ и очевидно дублирует классический foreach.
Лучше бы и у листа не было.
0
Нужно отталкиваться от удобочитаемости. Если логика обработки каждой записи достаточно сложная, то конечно же лучше использовать классический foreach. Если же нужно сделать что-то простое вроде emails.ForEach(m => SendMail(m)) (а еще лучше — emails.ForEach(SendMail)) — то LINQ гораздо лаконичней.
+1
Лучше исходить из того что side-effect-less код можно совать в лямбды extension-методов LINQ, а то что вы написали — нет.
0
Если воспринимать linq только по его последней букве q от query, то да, код, который исходную последовательность может изменить туда лучше не ставить, и да, ForEach тогда не нужен, ибо это практически его предназначение. А если этот метод воспринимать не как один из запросов, а как инкапсулированный обычный foreach, и использовать его для того, чтобы код был более читаемым и менее громоздким — почему бы и нет. В сочетании с другими операторами линка, записанными одной последовательностью через точку это выглядит гармоничнее, чем обычный foreach.
0
>Особенно после вчерашнего поста юзера SergeyT
Пост прошлогодний, глобально же вы мыслите :)
Что касается библиотек на .NET от Джона Скита, ещё вполне интересны protobuf-csharp-port и unconstrained-melody.
Первая понятно о чём (кстати, есть более активно развивающаяся альтернатива — protobuf-net), а вторая позволяет задавать нетипичные ограничения для generics.
Правда сложилось так, что ни одним из них сам не пользовался, но имею в виду, если попадётся подходящая задача.
Пост прошлогодний, глобально же вы мыслите :)
Что касается библиотек на .NET от Джона Скита, ещё вполне интересны protobuf-csharp-port и unconstrained-melody.
Первая понятно о чём (кстати, есть более активно развивающаяся альтернатива — protobuf-net), а вторая позволяет задавать нетипичные ограничения для generics.
Правда сложилось так, что ни одним из них сам не пользовался, но имею в виду, если попадётся подходящая задача.
+1
>>Index Возвращает последовательность пар индекс-значение.
Select из коробки так умеет (одна из его перегрузок)
Select из коробки так умеет (одна из его перегрузок)
+2
Очень полезно, спасибо. Например, ЗИПа нет под WP, пришлось брать реализацию из Скитовского же Reimplementing LINQ to Objects, а тут сразу такая библиотечка. Странно, что раньше ее не заметил.
0
Вот этим, наверное, вдохновлялся
www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html
:)
www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html
:)
0
Я думаю многим читателям блога .Net знакомо имя John Skeet.
Jon Skeet пишется без «h», фишка у него такая.
+1
У команды Rx есть Ix (Interactive extensions), доступный в NuGet. Там есть EnumerableEx, который всё то, что есть в Rx для IQueryable повторяет для IEnumerable. Ну так вот там списочек расширений подлиннее немного.
А morelinq посмотрим, спасибо.
А morelinq посмотрим, спасибо.
+2
Полезная библиотека. Не придется теперь создавать свои велосипеды.
0
Не совсем понятен смысл DistinctBy().
Пример:
В результате numbers содержит две цифры: 1 и 7, хотя должен содержать только цифру 7.
Пример:
List<int> list = new List<int>() { 1, 3, 4, 5, 7, 8, 23 };
List<int> numbers = list.DistinctBy(x => x > 5).ToList();
В результате numbers содержит две цифры: 1 и 7, хотя должен содержать только цифру 7.
0
Нет, просто перевод неточен.
0
Потому что с переводом налажали. В реальности там для каждого элемента последовательности применяется описанное преобразование и берутся те элементы (я так понимаю, что первые), у которых различаются результаты преобразования.
В вашем случае это преобразование, которое возвращает
В вашем случае это преобразование, которое возвращает
true
для всех элементов больше 5 и false
для всех остальных. Результат понятен.0
Нет. Уникальные по значению предиката.
1 — false, берем
3..5 — false пропускаются
7 — true, пропускаем
8..29 — true, пропускаем.
1 — false, берем
3..5 — false пропускаются
7 — true, пропускаем
8..29 — true, пропускаем.
0
Хорошая библиотека, надо брать. Сразу навскидку — оператора ForEach сильно не хватало. Приходилось делать Select, возвращать что-нибудь ненужное и результат выполнения никуда не класть. Не покидало гадливое чувство кривости получившегося кода. Все хотел свой extension метод писать, но как то руки не доходили.
0
Sign up to leave a comment.
Библиотека morelinq: то, чего не хватает в LINQ to Objects из коробки