Skip to content

Promotion InterpreterExpressions to lambda expressions#266

Merged
metoule merged 3 commits intodynamicexpresso:masterfrom
metoule:fix_262
Dec 1, 2022
Merged

Promotion InterpreterExpressions to lambda expressions#266
metoule merged 3 commits intodynamicexpresso:masterfrom
metoule:fix_262

Conversation

@metoule
Copy link
Copy Markdown
Contributor

@metoule metoule commented Nov 27, 2022

When a method parameter is a fully closed generic type (ie doesn't depend on a method generic's parameters), we never converted the parsed lambda expression to an actual expression.

Example:

[Test]
public void Lambda_Issue_262()
{
	var list = new List<int> { 10, 30, 4 };

	var options = InterpreterOptions.Default | InterpreterOptions.LambdaExpressions;
	var interpreter = new Interpreter(options);
	interpreter.SetVariable("b", new Functions());
	interpreter.SetVariable("list", list);

	var results = interpreter.Eval<List<int>>(@"b.Add(list, t => t + 10)");
	Assert.AreEqual(new List<int> { 20, 40, 14 }, results);
}

public class Functions
{
	public List<int> Add(List<int> list, Func<int, int> transform)
	{
		return list.Select(i => transform(i)).ToList();
	}
}

In that case, Func<int, int> is a fully closed generic type, and thus t => t + 10 was never converted to the proper Linq expression.

Note: I also fixed a bug where in b.Add(list, t => t + 10), list, t was improperly seen as the two arguments to the lambda expression.

Fixes #262

@metoule metoule merged commit 0940969 into dynamicexpresso:master Dec 1, 2022
@metoule metoule deleted the fix_262 branch December 1, 2022 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Call a custom method. The parameter is an expression

2 participants