Status: closed Implementation work Blocked
Source: Goldman Sachs ( Octavian Patrascoiu)
Currently there are three kind of functions in DMN / FEEL:
- builtin functions (see page 130), strongly typed with optional parameters and var args, with static typing.
- DMN functions defined in the metamodel (see functionDefinition element in xsd schema), strongly typed, with static binding
- FEEL functions defined in FEEL (see grammar rule 57), weakly typed with dynamic typing.
Mixing both static typing and dynamic typing in the same language is not a great idea from the execution point of view.
I am not a fan of dynamic typing mainly because it pushes semantic rules in the dynamic semantics and diminishes the quality of software products (e.g. increases maintenance costs) .
Imagine for example a context that contains an entry x with
function(a, b) a + b
and another one calling
The semantic analyzer cannot type check and infer the return type of the definition, it has to wait until the function is invoked. The type of x is partial (unknown parameter types and return types) for the rest of execution.
On top of that the function can be used both for numbers and strings. If the intended behavior changes over time for one use case the user has to write another function anyway.
It gets even harder to handle type checking for external functions.
I suggest adding an a parameter type in rule 58
formal parameter = parameter name ":" type name
where type name is a FEEL type or a complex type (defined via a typeRef)
Reported: DMN 1.1 — Fri, 25 Aug 2017 09:12 GMT
Disposition: Duplicate or Merged — DMN 1.2
part of improved types/itemdefinitions
DMN12-216adds optional types to FEEL functions
Updated: Wed, 3 Oct 2018 14:17 GMT