DROOLS-1701 fix: ranges cannot be (always) promoted to fields

[evacchi]

it won't work if boundaries are non-constants!

+17 tests pass, 95 yet to go!

[tarilabs]

If I well understand you are saying, for a range like:
[1..3]
we can have it as a Constant/fields in the generated Java class as it was before.
While for cases like
[nameref1..nameref2]
the above strategy cannot work because nameref1 cannot be resolved statically.

If my understanding is correct: Can you slight refactor this PR so that, if the range endpoint is a NumberLiteral, it take the "old" strategy for Constant/fields, while it goes into this new strategy for any other case, please? In most model I've seen personally [numberliteral..numberliteral] is used a lot. I would like to keep that as a constant if possible. Thanks.
If my understanding is not correct: please explain further? :)

[evacchi]

you are right. I have reverted to the (more general) runtime resolution of the boundary expressions. I'll try and handle both the constant and the non-constant case, even if it is slightly non-trivial, because of the way sub-expressions are resolved!

[evacchi]

wait, no. that's not what's happening. In fact, the case when it's a numeric is still working as expected

    /**
     * FEEL: [1..2]
     */
    @Override
    public Object apply(EvaluationContext feelExprCtx) {
        return new org.kie.dmn.feel.runtime.impl.RangeImpl(org.kie.dmn.feel.runtime.Range.RangeBoundary.CLOSED, (java.lang.Comparable) K_1, (java.lang.Comparable) K_2, org.kie.dmn.feel.runtime.Range.RangeBoundary.CLOSED);
    }

    public static final java.math.BigDecimal K_1 = new java.math.BigDecimal(1, java.math.MathContext.DECIMAL128);

    public static final java.math.BigDecimal K_2 = new java.math.BigDecimal(2, java.math.MathContext.DECIMAL128);

BTW your observation makes sense and I'll take a look

EDIT: nope, the original version stored the Range as a constant field. Alrighty.

[tarilabs]

In fact, the case when it's a numeric is still working as expected

not entirely, before that new RangeImpl was an initializer in a field definition (of a constant) in the rendered class.

[evacchi]

down to 88 failed tests, constant field restored for numeric ranges

[tarilabs]

One request to move a method then we're good to go

[tarilabs]

I believe this method is not currently shared with the AST-interpreted,
so better to move into CompiledFEELSemanticMappings as sounds analogous to the FEEL list and other constructs there.

[evacchi]

ay ay captain

[tarilabs]

thanks!