You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no general mechanism for a parent node to pass information to the child node's WriteNode call. We're already running into this:
Distinguishing between parameter declarations and parameter usage: the node itself in both cases is a ParameterExpression
Distinguishing between different block types: is this the block of a function, which (for the C# renderer) means we need to insert the return keyword before the last rendered subexpression? Or is it within the test of an if, and the subexpressions in the block have to be separated with , instead of ;?
We could resolve this in one of two ways. Either:
Every method should take an additional metadata object parameter. Since the base class doesn't know anything about the type of the metadata object, the type of the parameter should be object, or
Every method's parameter should be OneOf<T, IWrapper<T>>, where IWrapper<T> can produce a T.
The second way is appealing because it would also allow creating pseudo-TExpressions and passing them around as if they were the real thing. This would be a great benefit when extending an expression tree with custom types, much like SwitchExpression uses SwitchCase instances.
The text was updated successfully, but these errors were encountered:
Currently there is no general mechanism for a parent node to pass information to the child node's
WriteNode
call. We're already running into this:ParameterExpression
return
keyword before the last rendered subexpression? Or is it within the test of anif
, and the subexpressions in the block have to be separated with,
instead of;
?We could resolve this in one of two ways. Either:
object
, orOneOf<T, IWrapper<T>>
, whereIWrapper<T>
can produce aT
.The second way is appealing because it would also allow creating pseudo-
TExpression
s and passing them around as if they were the real thing. This would be a great benefit when extending an expression tree with custom types, much likeSwitchExpression
usesSwitchCase
instances.The text was updated successfully, but these errors were encountered: