I can access a nested property of a variable by using a dynamic path

[saig0]

Is your feature request related to a problem? Please describe.
My process has the following variables:

x = {"y": {"z": 1}}

path = "y.z"

I want to access the nested property y.z of the variable x in a FEEL expression, for example, on an exclusive gateway.

Instead of using static access x.y.z, I want to use the other variable path to define the access dynamically.

Describe the solution you'd like
I can access the (nested) property of a variable by defining a variable as the path.

In FEEL, there is the function get value() that accesses a value of a context by a given key. We could extend the function to accept not only a single key but a list of keys. The list of keys is interpreted as the path.

get value(x, path)

// with `path` being a list of the keys `["y", "z"]`
get value(x, ["y", "z"])

An alternative to the list ["y", "z"] would a string "y.z". But this option is not preferred because it would require an implicit transformation of the string into a path with the parts y and z.

Describe alternatives you've considered
I access the (nested) property of a variable by using the static name x.y.z.

Additional context
Related support case: https://jira.camunda.com/browse/SUPPORT-15389

[korthout]

I want to use the other variable path to define the access dynamically.

An alternative to the list ["y", "z"] would a string "y.z". But this option is not preferred because it would require an implicit transformation of the string into a path with the parts y and z.

Your main proposal doesn't use the path variable. Either the transformation needs to happen in the FEEL function, or the user must perform it explicitly.

IMO, the implicit path transformation is easier to use. Are there any downsides to us performing this transformation implicitly?

[saig0]

Your main proposal doesn't use the path variable. Either the transformation needs to happen in the FEEL function, or the user must perform it explicitly.

Yes. In the example, I unwrapped the variable path. So, the solution should look like this:

get value(x, path)

With the given variables:

x        = {"y": {"z": 1}}
path   = ["y", "z"]

I updated the description. 👍

MO, the implicit path transformation is easier to use. Are there any downsides to us performing this transformation implicitly?

The option of using a list of keys is more aligned with the DMN spec. There is already an existing function context put(context, keys, value) with a similar argument keys of the type List<String>. So, the chance is high that the function will be adopted by the OMG.

The implicit conversion of y.x would be a very special case and would conflict with the existing get value() function if the key contains . in its name (which is possible in FEEL). So, the chance is lower that this solution will be adopted.