- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
Well, this is literally FirstOrDefault reimplemented with a few downsides like not working correctly because it misses the predicate check.
However I would generally not recommend trying to reimplement the basic LInQ methods for those reasons:
IEnumerator can be implemented as class or struct and this means you have to be super careful in how you handle them.
The actual methods use traditionally a ton of optimizations in the past to avoid costly heap allocations by creating for example an enumerator for arrays and other well known types.
Most relevant today: The Roslyn compiler is actually analyzing LInQ expressions and uses combined enumerators for common queries, which results in less heap allocations because only one enumerator will be needed (if at all). With a custom implementation you end up not getting this benefit, so it will end up pretty much always being worse.
Finally there's obviously expressions; it's not a major thing, but it is really annoying that obviously custom statements will not be recognize and supported by any expression parser. So there's a the disconnect that a it will work in memory but not as a meta construct when translated to other languages like SQL.
Admin
My frist thought upon reading the signature was that it should have been generic - there's usually nothing special about the items in a collection that would prevent that.
Then I read the rest and it made me want to puke. All over the dev who wrote this.
Admin
Amateur. I've once submitted a (true) story about how I converted a BASIC flavoured code-file in an embedded system (which exceeded 64kB - back then Notepad didn't load files larger than that.) I replaced that idiocy with about 40 lines of code.
Imagine you have a tank that needs its level transmitter to be calibrated. You fill it with water, and read the level transmitter, and record the volume of water pumped into the tank. So how did our bright antagonist convert this table into code? IF level => 0 AND level < 1 THEN volume = 0.63 IF level => 1 AND level < 2 THEN volume = 1.21
Yes, for each centimeter it would "look up" the correct volume. Note that those tanks were 40m tall. And there were 6 of them.
I replaced it with something like: volume = 0.6 * level (and yes, I did check that the error in my calculation was never greater than the error introduced by the "look-up table."
Admin
But you know what happens when you start culling code: somewhere, a function is lurking. It calls this particular function with a predicate, but if the predicate would be tested, another function, in a completely different part of the code, would mysteriously fail sometimes. Silently.