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