LINQ, Take Two: Realizing the LINQ to Everything Dream
Recorded at:
- Share
-
- |
Read later
Reading List
Bio
Bart De Smet is a Software Development Engineer on the Cloud Programmability team, an avid blogger and a popular speaker on various international conferences. In his current role, he’s actively involved in the design and implementation of Reactive Extensions for .NET (Rx) and on an extended “LINQ to Anything” mission.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Related Sponsor
Find out how Redgate’s Database DevOps Solution can help your team deliver value quicker and keep your data safe.
Not able to load Video
by
Ajay Bhosale
16:04:48:570 NetConnection.Connect.Closed
16:04:48:577 MediaPlayer.Error.FAILED TO PLAY X.MP4; STREAM NOT FOUND.
16:04:48:578 NetStream.Play.Stop ( x.mp4 )
It doesn't have to be IQueryable
by
Stefan Wenig
However, beyond the simple scenarios he shows there's little chance to get there. Take an O/R mapper, the most common scenario for LINQ providers. When we want to use our POCO classes for queries, we're out of luck here. Even if our query factory returns a MyQueryable<MyType> that does not implement IQueryable<MyType>, MyType will likely have members that implement IEnumerable<T>, and now any LINQ expression using these members will be compiled. Unsupported features will just break at runtime, and there's nothing you can do about it.
The consequence is that any useful LINQ provider needs to implement almost anything, or it will be useless because nobody wants to guess what's possible and then try it out and re-write it until it works. A complete LINQ provider is much harder to write than one that supports, say, 80% of query features. And there's alyways stuff that can _only_ be executed in memory (basically any user-defined method, comparers etc.)
We spent some time figuring out how we could add compile-time limitations to LINQ provider toolkit (relinq.codeplex.com), but it just doesn't work without generating specific queryable classes for any classes participating in queries. Which in turn would not only mess up the build process, but also create circular dependencies whenever you want to write a LINQ query in a queryable class.</t></mytype></mytype>
Re: It doesn't have to be IQueryable
by
Stefan Wenig
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think