Roadmap/missing features about linq-collections

[isc30]

that's lame, let the users (and benchmarks) decide which one is better 🤣

warning: the "better lib" is his library

[kutyel]

@apawsey or you could just use a decent LinQ implementation like this one 😉

[apawsey]

Haha... Thanks for the 👍
Yeah, so far I'm loving this... easy approach, totally intuitive for anyone having used linq before. Will happily contribute once I know the status of things!

Think you've got a good thing going here!

[kutyel]

Yeah I haven't seen the benchmarks but yours is 3x more code and therefore more useless code in the bundle, compare this with this 😂

[isc30]

More code doesn't mean less performance lol.... it means more functionality + tests
About benchmarkt, no worries, I just did one for you:

linq-collections: 116 ops/s

const list = new LinqCollections.List(data); // 100k elements
const array = list.distinct().toArray();

linq.ts: 0.18 ops/s

const list = new LinqTs.List(data); // 100k elements
const array = list.Distinct();

x3 more code, but x1000 better performance 🥇

[isc30]

i'll be adding a benchmarkt project, thanks for the idea 👍

[isc30]

Hi, thanks for your comment.
I just realized that you are totally right, no one except me knows what's currently missing.
Adding this will help both contributors and users! nice idea 👍

[isc30]

I created a project with current status of the things, can be found HERE
For first version, missing features are: skipWhile, sequenceEquals, longCount, join, intersect, groupJoin, toLookup. I would really love to see some contribution 😄 maybe easier thing for start is sequenceEquals

[apawsey]

Well I can tell you I picked this over yours @kutyel because yours has only lists... I wanted different types of collections. I don't think you can really claim to have a linq implementation if you only support one collection type... I guess you can have a lists of other types of things, but doesn't feel right to me. And to be fair... the benchmarks do kinda speak for themselves.

[isc30]

Hi Adam, thanks for sharing your reasons to pick my lib, this really helps a lot 😄

From my side, the main reasons to create my own lib were:

• Correct implementation (strict microsoft's standard with exceptions etc) + definitions
• REAL unit tests (currently > 2000)
• More (and better) collection types (dictionary...)
• ES5 compatibility (!!!!)
• PERFORMANCE (deferred execution, iterators, ...)

Bonus point: this lib is even faster than native JS approaches
Example of my .where vs native .filter: https://jsperf.com/native-vs-isc