[
https://issues.apache.org/jira/browse/METRON-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223827#comment-16223827
]
ASF GitHub Bot commented on METRON-1277:
----------------------------------------
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/814
@jjmeyer0 @cestella : Ok.
So, I added some code, where it is possible context wise to guard against
the case where there is a single variable as the check, and no default. This
resolves the test issues, save for one, where there is no default and we are
using == true. This is more difficult.
I feel as if all of these things are wrong, because the validation by
executing with null variables is itself logically wrong. We have discussed
this before, but this is really evident here. At least I feel it is.
I think that we should use compilation instead of validation. We can
decide to make it a separate option when running tests, or to make it the way
we do all tests etc. But if compilation does what I think it does, then I
think it is more correct.
I would like to do that, and remove the work around I have introduced here
( basically detecting that we are validating and have a single var that is null
because of validation ) since changing validation would be the real complete
answer.
> STELLAR Add Match functionality to language
> -------------------------------------------
>
> Key: METRON-1277
> URL: https://issues.apache.org/jira/browse/METRON-1277
> Project: Metron
> Issue Type: New Feature
> Reporter: Otto Fowler
> Assignee: Otto Fowler
>
> From dev list:
> ------------
> Hi All,
> It's high time that Stellar supports some form of conditional that is
> beyond if/then/else. Right now, the way to do fall-through conditionals is:
> if x < 10 then 'info' else if x >= 10 && x <= 20 then 'warn' else 'critical'
> That becomes non-scalable very quickly. I wanted to facilitate a
> discussion with the community on the syntax. I'll give a few options and
> you guys/gals can come up with your own suggestions too, but I wanted to
> frame teh conversation.
> *MAP-BASED SWITCH*
> With the advent of METRON-1254 (https://github.com/apache/metron/pull/801),
> we could enable (from a language perspective in Stellar) multi-part
> conditionals or switch/case style statements. To wit:
> MAP_GET(true, { x < 10 : 'info', x >= 10 && x <= 20 : 'warn', x > 20 :
> 'critical' })
> Or, with a convenience function:
> CASE( { x < 10 : 'info', x >= 10 && x <= 20 : 'warn', x > 20 : 'critical' }
> )
> The issue with this is that the last true condition wins because we're
> using a map.
> *LIST-BASED SWITCH*
> We could correct this by adding a list of pairs construction to stellar:
> CASE( [ x < 10 : 'info', x <= 20 : 'warn'], 'critical')
> This would enable us to allow the first true condition to win, so the
> second condition can be simpler and we could pass a default return value as
> the final argument.
> The downside to this, is that it requires a language enhancement (the list
> of pairs construction you see there).
> *LAMBDA FUNCTION-BASED SWITCH*
> Some of the problems with the previous statements are that every
> conditional has to be evaluated and there is no opportunity to short
> circuit. They're all evaluated at parse-time rather than execution time.
> We could, instead, construct a lambda function approach to this and support
> short-circuiting in even complex conditionals:
> CASE( real_variable_name, [ x -> x < 10 ? 'info', x -> x <= 20 ? 'warn' ],
> 'critical')
> or
> CASE( real_variable_name, [ x -> if x < 10 then 'info', x -> if x <= 20
> then 'warn' ], 'critical')
> This would require lessening ?: (if/then/else) syntax to support to enable
> just if without else conditions. This also has the benefit of allowing
> simplifying the expression due to lambda function variable renaming
> (real_variable_name can be much more complex (or even an expression) than
> 'x'.
> Creative other approaches to this are appreciated!
> Thanks,
> Casey
> ----------------
> and ->
>
> How about this:
> match(VAR_TO_VAL_ASSIGNMENT+) { BOOLEAN_STATEMENT(VALS) : LAMBDA(VALS),
> BOOLEAN_STATEMENT(VALS) : LAMBDA(VALS) , LAMBDA(VALS)}
> * match = new keyword
> * match takes variable number of assignments, where the val assigned to is
> available in the evaluation and the lambdas
> * match {} contains comma separated list of a statement that evaluates to a
> boolean and a lambda
> * LAMBDA is executed on match, and it’s value is returned
> * no matches returns null or return of optional final statement, which is a
> LAMBDA without a BOOLEAN_STATEMENT
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
