Indeed, and Jeff demonstrates. C# would embed such things as constant expressions or variables (as opposed to parameters), and LINQ to SQL knows to pull those in. No problem.
As I mentioned, being able to (inasmuch as possible) mimic C# and VB's expression tree output should be the target. Anything arcane, really, need not be supported yet. The goal is compatibility with the more interesting providers, which were developed with those trees in mind. This in itself doesn't preclude EF or LINQ to SQL from gaining dynamic support at a later point (although dynamic typing may), nor would it necessarily preclude being able to emit the dynamic call sites if there's nothing better (in which case, you *could* have DLR-specific APIs that consume more interesting trees). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Hardy Sent: Tuesday, December 22, 2009 2:12 PM To: Discussion of IronPython Subject: Re: [IronPython] LINQ from IronPython On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland <[email protected]> wrote: > The really interesting thing to me is that this is a closure - either id is in > a nested function scope or it's in a global scope. I'm not sure how that gets > transmitted across the wire. Do closures work in LINQ in C# going across to > a database? Yep: int id = 1; var result = customers.Where(c => c.Id == id); would become a parametrized SQL query: SELECT * FROM Customers AS t0 WHERE t0.Id = @p0; where @p0 is the parameter passed along with the query, with the value 1. - Jeff _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
