The old method was to keep a NRefactory expression for each node.
The new method is create a lambda expression for each node.
The main motivation for this change is to get ready for NR5 which does not allow any sharing of AST nodes. This would mean that we would have to create a complete AST for each node, which might get expensive for deeply nested nodes. Caching of already evaluated expression would also be more difficult with separate ASTs. ILSpy is based on NR5 so we need this solution for it right now.
Another disadvantage was that every operation had to go though AST so we had to support it in the evaluator, we had to generate the AST, and we had to hope that nothing breaks on the way. This is particularly complex for types - with lambda expression we simply keep around the reference to the type or to whatever we need. Some things like "current exception object" do not exist in the AST so we had to hack around it.
On the other had, it was nice to have accurate C# expression for all nodes - for pretty printing, editing, or saving/loading it.
The old method was to keep a NRefactory expression for each node.
The new method is create a lambda expression for each node.
The main motivation for this change is to get ready for NR5 which does not allow any sharing of AST nodes. This would mean that we would have to create a complete AST for each node, which might get expensive for deeply nested nodes. Caching of already evaluated expression would also be more difficult with separate ASTs. ILSpy is based on NR5 so we need this solution for it right now.
Another disadvantage was that every operation had to go though AST so we had to support it in the evaluator, we had to generate the AST, and we had to hope that nothing breaks on the way. This is particularly complex for types - with lambda expression we simply keep around the reference to the type or to whatever we need. Some things like "current exception object" do not exist in the AST so we had to hack around it.
On the other had, it was nice to have accurate C# expression for all nodes - for pretty printing, editing, or saving/loading it.
- Simple dynamic code generation seems to trigger both callbacks.
- IronPython for some reason causes just the LoadClass callback so we choose to rely on it out of the two.
git-svn-id: svn://svn.sharpdevelop.net/sharpdevelop/trunk@6111 1ccf3a8d-04fe-1044-b7c0-cef0b8235c61
Variable Tree Model modified so that it supports lazy evaluation (for scrolling)
git-svn-id: svn://svn.sharpdevelop.net/sharpdevelop/trunk@4555 1ccf3a8d-04fe-1044-b7c0-cef0b8235c61
Fixed a bug for AppDomains - the AppDomain for threads can change
git-svn-id: svn://svn.sharpdevelop.net/sharpdevelop/trunk@4521 1ccf3a8d-04fe-1044-b7c0-cef0b8235c61
Cleaned up using Statements.
added some Exception xml doc blocks.
Updated the projects to Visual Studio 3.5
git-svn-id: svn://svn.sharpdevelop.net/sharpdevelop/branches/3.0@3648 1ccf3a8d-04fe-1044-b7c0-cef0b8235c61
David Srbecký
Daniel Grunwald
Siegfried Pammer
Eusebiu Marcu
mkonicek
Matt Ward
Justin Dearing