Source: Red Hat Inc ( Edson Tirelli)
This is a suggestion for future versions of the spec:
Add support for Unary Tests as first class citizens of the FEEL language, in a similar way as ranges and functions already are.
A unary test is really a “predicate”: a single parameter function that returns a boolean. It is syntax sugar on:
function ( x ) x in <unary_test>
FEEL already supports functions as first class citizens, so it makes sense to support Unary Tests. The following two syntaxes would then be equivalent:
is minor : < 18
is minor : function( age ) age in < 18
Invoking unary tests explicitly would be like invoking a function:
Bob is minor : is minor( bob.age )
More importantly, it would allow the implementation to actually support passing unary tests as parameters to functions and make the example on page 115 viable:
decision table (
outputs: "Applicant Risk Rating",
input expression list: [Applicant Age, Medical History],
rule list: [
[ >60, "good", "Medium" ],
[ >60, "bad", "High" ],
[ [25..60], -, "Medium" ],
[ <25, "good", "Low" ],
[ <25, "bad", "Medium" ]
hit policy: "Unique"
Unary test syntax is not ambiguous, so supporting it would mean to basically change rule 2 in the grammar to include rules 14 and 17 as possible options. The semantic mapping table on page 116 would also need to include a new FEEL value type: "unary test".
Reported: DMN 1.1 — Tue, 23 Aug 2016 01:41 GMT
Updated: Tue, 22 Jan 2019 04:00 GMT