Rules and return codes

[florian-h05 (Florian H.)]

@Nadahar

Yes, I thought of that too, but it would mean that conditions would have to be written “using different rules” than actions - maybe not ideal? Also, as I said, actions can also return values, although rarely used.

The whole „implicit“ return stuff in conditions in kind of shady, so IMO would mean nothing bad if one needs to explicitly return in these actions.

@rlkoshak

Don’t get me wrong, I much prefer having an explicit return. But making the wrapper configurable adds all kinds of headaches. You can never know from within the rule what to do.

What about always enabling it then? Sure, it is a breaking change but if we clearly communicate it, avoid confusion by giving no choice, then it should be possible to get along with it. Adding return isn‘t that complicated and if we provide the right query for the developer searchbar, it should be easy to locate all conditions.
Rules can now also be regenerated from templates thanks to @Nadahar.
Also don‘t forget that the pure JS event object isn‘t available without the wrapper.

@Nadahar

And this was my point above, somewhere this logic must exist, and it should be possible to refine so that it only adds the “implied return” where appropriate, as long as it doesn’t reside in the script engine (Graal) itself.

You can check ScriptConditionHandler in core, the condition is just the plain script that is passed to ScriptEngine::eval or CompiledScript::eval.
Given that ScriptEngine::eval allows for stuff like eval(„10 > “), I think it is expected that the „implicit“ return works. As long as the global script ends its execution with a boolean value, it is considered (at least it seems to me) to have returned this (you cannot really return from a global script, hence the error if return is used without wrapper).

Just seen that Nadahar googled this, and I agree with him on the house of cards wrt to script identifiers (@Nadahar I have seen your issue, wanted to answer).