Resolving of dynamic object members about nrefactory HOT 6 CLOSED

Hi,
Any news / updates regarding this issue?

Thanks!

from nrefactory.

Hi,

I've modified a very small piece of code, which totally resolves this issue, please consider it:

class CSharpResolver
{
    static ResolveResult DynamicResult { get { return new ResolveResult(SpecialType.Dynamic); } }

}

The previous code had a single const object for this.
This code will create a new resolve result object for every dynamic object expression, which helps resolving back to the original expression.

from nrefactory.

Yes, I guess we'll need to stop reusing ResolveResults. This is not only a problem for dynamic, there are a couple of other cases where ResolveResults are cached (member lookup cache, voidResult, maybe more).

from nrefactory.

Yes, this might be an issue, although from all the code I've tested, most of the other cached ResolveResults are pretty harmless. My issue happens when I begin resolving an expression, then I have a whole new tree to visit (ResolveResult tree), most of the time, I can perform all calculations directly on ResolveResults, but in some cases (lambda expressions, delegates, dynamics), I must have the original expression back. During this time I'm so deep inside ResolveResults, that the only way to resolve it back is using the dictionary. So, only then, if I have more than one expression for a resolve result, I can't continue.

BTW: I've implemented two ResolveResult visitors, for both Core and CSharp namespaces, I saw some people asking for it, so if you want to integrate it, let me know and I'll send it to you.

from nrefactory.

Well, the others might be harmless for your usecase, but it would be nice to have the ResolveResult -> AST mapping work in general.

I'm not sure if the visitor pattern is a good idea for ResolveResults.

1. The separation into language-independent and C#-specific results is a bit messy.
2. ResolveResults derive from other non-abstract ResolveResults.
   E.g. VisitInvocationResolveResult() wouldn't get called for all invocations, as the CSharpInvocationResolveResult would call another visit method. (for the AST, we've taken care to derive only from abstract node types)
3. It's possible that we add additional ResolveResults in the future to represent cases that currently only return a general ResolveResult. Implementing the visitor pattern makes every such addition a breaking change.

We've written some ResolveResult-traversing code using dynamic in SharpDevelop, and I think I'm preferring that approach over the visitor pattern.
https://github.com/icsharpcode/SharpDevelop/blob/newNR/src/AddIns/Debugger/Debugger.AddIn/NRefactory/ExpressionEvaluationVisitor.cs

from nrefactory.

Regarding ResolveResult mapping:
Cool, a general solution will be great, thanks!

Regarding Visitor pattern:
Got it, thank you for the example, since I need a performance critical solution, I'll keep using the visitor pattern myself, I don't mind refactoring when breaking changes are made.

Thank you for your swift and detailed answer.
Cheers!

from nrefactory.