Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/687
OK,
The others can comment, but I think proper scope would be implemented
within the execution of the call stack, not arbitrarily by the resolvers. Each
resolver should be a 'scope' and new scopes should be created.
A. Because it is a resolver thing, where would you document it in a way
that makes sense? I have been thinking that we should refactor to explicitly
support scoping in the processor/evaluations and then have the resolvers _used_
in scope as scope implementations. So the nesting of scopes would not be done
in the resolver.
B. As noted in the PR description, I was hoping for discussion ( THIS
discussion as a matter of fact ). Having had some issues with my other PRs and
scope, I chose to explicitly NOT go that far until we talked it through. I did
not feel all the way back then that I had enough of a grasp of the different
resolvers to change their behavior and understand the consequences either way.
C. The LambaExpression actually delegates to the state variable resolver:
```java
VariableResolver variableResolver = new DefaultVariableResolver(
variable -> lambdaVariables.getOrDefault(variable
, state.variableResolver.resolve(variable)
), variable -> true,
(variable, value) -> {
if (state.variableResolver.exists(variable)) {
state.variableResolver.update(variable, value);
}
});
```
D.
- I think I answered above.
- I *think* so, maybe @cestella or @nickwallen can answer that
- Again, I stopped short until I got some kind of feedback.
- I have changed StellarAssignment, I don't think we need both `=` and
`:=`, and if there are `:=` floating around they will work, unless we remove
StellarAssignment
---
