Bart De Smet presents LINQ’s origins, its current status, and plans for the future which include LINQ to Everything, plus discussions on theorem solving, reactive queries, and query optimization.
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.
Not able to load Video
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
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>