Здравствуйте, AndrewVK, Вы писали:
U>>Издеваешься? FirstOrDefault это вообще крайне опасная операция, т.к. если match у нас, к примеру, int
AVK>В таких случаях int просто заменяется на int?
Здравствуйте, AndrewVK, Вы писали:
AVK>>>В таких случаях int просто заменяется на int?
L>>Где именно? В типе match или в коллекции items?
AVK>Где удобнее.
Здравствуйте, Silver_s, Вы писали:
S_>>Ну там тоже можно сделать: S_>> matches.Select(_=>(int?)_).FirstOrDefault() S_>А если часто такое писать, то лучше аналог такой функции реализовать: S_>
Во-первых, коллекция может не вернуть Count(), например если это бесконечная коллекция.
Во-вторых, коллекция не обязана всегда возвращать согласованный результат при разных запросах, например если это L2S-запрос, то при определенном уровне изоляции транзакций, первый Count() может вернуть число отличное от 0, но последующий First — ничего не вернуть.
Если уж нужно что-то подобное, то используйте подход как у Dictionary:
public static bool TryFirst<T>(this IEnumerable<T> src, out T value) {
try {
value = src.First();
return true;
} catch (InvalidOperationException) {
value = default(T);
return false;
}
}
Хотя этот код тоже далек от идеала: InvalidOperationException вполне может быть выброшен не непосредственно First-ом, а коллекцией src.
Вариант с ручным перебором наверное будет-таки "честнее":
foreach (T elem in src){
value = elem;
return true;
}
value = default(T);
return false;
Здравствуйте, AndrewVK, Вы писали:
AVK>В нем, скорее всего, проще будет применить FirstOrValue. Ну либо конвертировать в int? matches.
Давно сделал bool TryGetFirst<T>(this IEnumerable<T> source, out T value) и не мучаюсь с семантикой. Для извращённых сценариев (пока не понадобилось) можно изобрести Option<T> или использовать Lazy<T> в 4-м фреймворке (кстати, может там и Option<T> уже есть?).
А развели-то...
Слово К.О.: С null засада в том, что не всегда очевидно что получили: null как допустимое значение или null как "не найдено".
С extensions и/или LINQ синтаксисом вариант в плане читаемости проигрывает. В данном случае можно обойтись foreach. Возможно, стоит части кода вынести в отдельные методы, которые стоит назвать по их смыслу. Ниже приведу пример (только пример ) :
private void Collect(IService sr, ObjectCategories protection)
{
foreach (NetworkConnection networkConnection in GetServiceConnections(sr))
Collect(networkConnection, protection);
}
private IEnumerable<NetworkConnection> GetServiceConnections(IService service)
{
List<NetworkConnection> networkConnections = new List<NetworkConnection>();
foreach (ServiceSegment segment in GetServiceSegments(service))
foreach (NetworkConnection networkConnection in GetSegmentConnections(segment))
networkConnections.Add(networkConnection);
return networkConnections;
}
private IEnumerable<ServiceSegment> GetServiceSegments(IService service)
{
List<ServiceSegment> segments = new List<ServiceSegment>();
foreach (ServiceSegment item in service.WorkingSegments)
segments.Add(item);
foreach (ServiceSegment item in service.ProtectionSegments)
segments.Add(item);
return segments;
}
private IEnumerable<NetworkConnection> GetSegmentConnections(ServiceSegment segment)
{
List<NetworkConnection> networkConnections = new List<NetworkConnection>();
foreach (SegmentParcel parcel in segment.SegmentParcels)
if (parcel.NetworkConnection != null)
networkConnections.Add(parcel.NetworkConnection);
return networkConnections;
}
Здравствуйте, sashar2, Вы писали:
S>С extensions и/или LINQ синтаксисом вариант в плане читаемости проигрывает. В данном случае можно обойтись foreach. Возможно, стоит части кода вынести в отдельные методы, которые стоит назвать по их смыслу. Ниже приведу пример (только пример ) :
Это очень тяжелый код. Undying показал самое лучше из императивщины.
Здравствуйте, AndrewVK, Вы писали:
U>>Издеваешься? FirstOrDefault это вообще крайне опасная операция, т.к. если match у нас, к примеру, int
AVK>В таких случаях int просто заменяется на int?
Т.е. если у нас есть коллекция int'ов, то ее надо явно преобразовывать в коллекцию Nullable<int>? Это очень удобно?
Функция FirstOrDefault в фрамеворке это ошибка дизайна, если бы вместо нее были бы функции FirstOrNull для коллекций классов и FirstOrNullable для коллекций структур, то проблем не было бы в принципе.
Здравствуйте, Undying, Вы писали:
AVK>>В таких случаях int просто заменяется на int?
U>Т.е. если у нас есть коллекция int'ов, то ее надо явно преобразовывать в коллекцию Nullable<int>? Это очень удобно?
U>Функция FirstOrDefault в фрамеворке это ошибка дизайна, если бы вместо нее были бы функции FirstOrNull для коллекций классов и FirstOrNullable для коллекций структур, то проблем не было бы в принципе.
С FirstOrNull проблемы никуда не ушли бы, т.к. null — вполне себе допустимое зачение для ссылочного типа, а значит может встретиться в коллекции.
Да и с FirstOrNullable — непонятно тогда, как работать с коллекцией nullable-ов, ведь Nullable<T> — сама по себе структура.
Здравствуйте, Lloyd, Вы писали:
L>С FirstOrNull проблемы никуда не ушли бы, т.к. null — вполне себе допустимое зачение для ссылочного типа, а значит может встретиться в коллекции.
И сколько раз в жизни ты писал код, в котором при получении первого элемента требовалось разделять ситуации 1) коллекция пуста 2) в коллекции первый элемент null?
Я вот ни разу, и даже задачу где бы это требовалось придумать не могу.
Здравствуйте, Undying, Вы писали:
L>>С FirstOrNull проблемы никуда не ушли бы, т.к. null — вполне себе допустимое зачение для ссылочного типа, а значит может встретиться в коллекции.
U>И сколько раз в жизни ты писал код, в котором при получении первого элемента требовалось разделять ситуации 1) коллекция пуста 2) в коллекции первый элемент null?
Тогда тем более непонятно зачем вводить FirstOrNull, если он не решает тех проблем, которые есть у FirstOrDefault.
Объясните как такие задачи решать в чисто функциональном стиле?
Соответственно получается, что даже если виртуозно владеешь функциональным стилем, все равно для записи сложных алгоритмов нужно не хуже владеть стилем императивным.
Здравствуйте, Lloyd, Вы писали:
U>>И сколько раз в жизни ты писал код, в котором при получении первого элемента требовалось разделять ситуации 1) коллекция пуста 2) в коллекции первый элемент null?
L>Тогда тем более непонятно зачем вводить FirstOrNull, если он не решает тех проблем, которые есть у FirstOrDefault.
Не понял ответа. Если разделять ситуации коллекция пуста и первый элемент коллекции null не требуется, то использовать функции FirstOrNull и FirstOrNullable безопасно, в отличии от функции FirstOrDefault.
) :
