Are there facilities to convert a Func<T> and an Expression<T> in order to use something that was intended to be used as a predicate and use it instead as an expression tree
I was thinking of a really simple scenario with a Repository pattern where the Repository has a local cache of objects as well as a reference to a data access object. If the object is not found in the local cache, it's looked up using the data access object. If a Func<T> is passed into the Repository's Get() method, it could be used directly against a cache of List<T>. However, if the object is not found in the cache, the lambda would need to be converted to an expression tree and passed into a custom query parser. Implementing a custom List<T> to work with an Expression<T> tree would do it, but that's a PITA. Oh well.
I am sure reflector statements don't map one on one to the expression tree statements. But Reflector does probably build up an expression tree internally, and then uses an language writer for showing that expression tree in that particular language. But then again i don't know how the internals work in lutz's reflector. Maybe its less work to do it be scratch after all.
...not really the in-the-box experience I was hoping for. My hope was to capture a lambda and use it either as an expression tree or a predicate - to use the same lambda against a local cache based on a List<T>, or to convert it to another query syntax. I guess I'm a little disappointed that this use case isn't supported, but it is early in the game yet. I'd at least hope that this scenario has been identified.
Damn I love LINQ… I just hope it will ultimately be built to support contemporary design and practice patterns that MSDN has yet to recognize. Sure would be nice to have some insight into LINQ's user stories, and target audience justifications.
I should hopefully have it posted this month if I have time to finish up some of the smaller bugs I've noticed, however the IL -> Expression tree code is pretty much complete.
This is not an IL -> Expression Tree sample for the LINQ project though, it is part of a project to replicate some LINQ functionality in 2.0 without needing a custom compiler.
It's one thing to take the bytecode for a method and print out the opcodes. It's another to translate that into any particular language (it may indeed be impossible), which is what the expression tree represents. Yes, he can do it, but it's done on a language-by-language basis. You'd need to create a plugin for reflector to do the same.
What I don't know is whether the conversion that happens in the preview compiler is purely compiler-magic or whether it would be feasible to add implicit conversion operators to Delegate. If the latter is doable, then you don't have to change the compiler to do lambda -> tree or lambda -> func conversion, making it much more immediately useful to other languages.
Convert it Runtime I dont think so, its an compiler trick afaik . Im afraid they need an extra layer of indirection for that. So i guess its not possible yet. I tried to achieve the same thing for an kind of Linq query analyzer but ended up writing my own interpreter. There is however a sample on how you can create your own interpreter and create a delegate for it, i guess you can do the same thing with some effort for an expression tree.
Convert between Func<T> and Expression<T>
colinfahey
j_welch2
winstonkl
Great! Looking forward to seeing what you've come up with.
-Scott
Mr Spock
Ricardo Tome
<sigh />
-Scott
RayClark096
kuzmaster
...not really the in-the-box experience I was hoping for. My hope was to capture a lambda and use it either as an expression tree or a predicate - to use the same lambda against a local cache based on a List<T>, or to convert it to another query syntax. I guess I'm a little disappointed that this use case isn't supported, but it is early in the game yet. I'd at least hope that this scenario has been identified.
Damn I love LINQ… I just hope it will ultimately be built to support contemporary design and practice patterns that MSDN has yet to recognize. Sure would be nice to have some insight into LINQ's user stories, and target audience justifications.
rahul93253
I should hopefully have it posted this month if I have time to finish up some of the smaller bugs I've noticed, however the IL -> Expression tree code is pretty much complete.
This is not an IL -> Expression Tree sample for the LINQ project though, it is part of a project to replicate some LINQ functionality in 2.0 without needing a custom compiler.
Ameya Barve
Amit Kapoor
It's one thing to take the bytecode for a method and print out the opcodes. It's another to translate that into any particular language (it may indeed be impossible), which is what the expression tree represents. Yes, he can do it, but it's done on a language-by-language basis. You'd need to create a plugin for reflector to do the same.
Eager_Beever
What I don't know is whether the conversion that happens in the preview compiler is purely compiler-magic or whether it would be feasible to add implicit conversion operators to Delegate. If the latter is doable, then you don't have to change the compiler to do lambda -> tree or lambda -> func conversion, making it much more immediately useful to other languages.
I think it'd cover your concern as well
Brian_76
Emily0724
Gabirucho
Convert it Runtime I dont think so, its an compiler trick afaik . Im afraid they need an extra layer of indirection for that. So i guess its not possible yet. I tried to achieve the same thing for an kind of Linq query analyzer but ended up writing my own interpreter. There is however a sample on how you can create your own interpreter and create a delegate for it, i guess you can do the same thing with some effort for an expression tree.
If you find a solution, please post here.
Regards,
Emile