You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this issue you seem to have introduced an option type for some of the linq functions, #133
However Linq original First and Hyperlinq first now have a different signature. Wouldn't it feel better to specify a new signature such as FirstOpt, FirstOption ? Actually this is what I've done for my own set of Linq extension methods.
It also prevents Hyperlinq to be a drag&drop solution as it will cause regression.
The text was updated successfully, but these errors were encountered:
Hyperlinq is not drag&drop in several cases. IEnumerable<> collections have to be converted to IValueEnumerable<> and IReadOnlyCollection<,> collections have to be converted to IValueReadOnlyCollection<,>. The operation AsValueEnumerable() has to be used for that. It's not required for arrays, Span<>, Memory<>, collections in System.Collections.Generic and in System.Collections.Immutable, because I have extensions for those.
My initial plan was to reproduce the LINQ API as much as possible. I since then changed my mind. I want to create a modern version of LINQ.
I did support First, Single, ElementAt, FirstOrDefault, SingleOrDefault and ElementAtOrDefault. The reason I longer do is that I have to implement them for arrays, Span, ReadOnlySpan, Memory, ReadOnlyMemory, IValueEnumerable, IValueReadOnlyCollection, IReadOnlyList, and IAsyncValueEnumerable. Plus, I have to have unit tests for all of these. I already have more than 7K unit test scenarios.
In #133 I explain all the alternatives I considered. I ended up choosing to return Option.
In this project, I already use source generators. I may consider your naming proposal and use generators to generate the extensions required to support the old behaviors.
Thanks for you thorough answer. I indeed believe you should stick with LINQ original naming when signature & behaviour are the same. If behaviour or signature changes then I would set a new name. I feel it's the best practice in what you're trying to create to avoid any headache to developers adopting your solution.
Not being drag & drop is not an issue in itself. Just misleading naming :)
I'm envisioning to try Hyperlinq out in the optimization process of Unity games where heap allocation is an issue.
In this issue you seem to have introduced an option type for some of the linq functions,
#133
However Linq original First and Hyperlinq first now have a different signature. Wouldn't it feel better to specify a new signature such as FirstOpt, FirstOption ? Actually this is what I've done for my own set of Linq extension methods.
It also prevents Hyperlinq to be a drag&drop solution as it will cause regression.
The text was updated successfully, but these errors were encountered: