2 ms·
Totally. I couldn't care less if the LINQ syntax had gone tomorrow, but functional composition is so powerful, and easier to maintain too.
by sedatk 2y ago
Totally. I couldn't care less if the LINQ syntax had gone tomorrow, but functional composition is so powerful, and easier to maintain too.
- recursive 2y agoI would miss it for `let`, and for multiple `from` clauses. These are things that can be done with extension methods and callbacks, just not as elegantly.
- sedatk 2y ago`let` is just a .Select(), isn't it?
- brewmarche 2y agoA `Select` to a tuple or anonymous class which you have to carry around all the way. If you look at how a LINQ query gets translated to a method chain (e.g. via SharpLab or let Rider/ReSharper rewrite them) you'll notice that multiple `from`s or `let`s can become quite ugly.
- progmetaldev 2y agoTo add on to what you wrote, it amazes me the number of developers that don't understand you can use .Select() to construct named object instances. I'm probably using bad terminology, but something like: .Select(x => new Employee { Name = x.Name, DepartmentName = x.Department.Name }).ToList();
- recursive 2y agoHow do these developers use .Select() then?
- progmetaldev 2y agoInto anonymous types mostly, where you can't pass the type to another method. Example: .Select(x => new { Name = x.Name, DepartmentName = x.Department.Name }).ToList(); Same code as I wrote, except capture in an anonymous type. The documentation practically encourages this.
- sedatk 2y agoOh that's convenient, that's for sure.
- wvenable 2y agoThere are some queries that are actually easier to compose in LINQ syntax than even in SQL. However, like everyone else, I rarely find myself actually using it. Anything really complex is done in pure SQL and everything else is method syntax. But it is slightly more expressively powerful than SQL and way easier to follow, if you need it, than the method syntax.