jens-maus
commented
6 years ago I fully agree that more of these features would be great. However, ReGaHss is so limited and not designed to host a procedural programming interface. That's why some of the greater functionality is not part of the official programming environment documented. So, I highly doubt that it will ever be possible with some minor work to integrate such features in ReGaHss in a smooth and straight forward way that a future version can provide that functionality to end users.
However, I will keep that ticket open and assigned to the ReGaHss "project". Nevertheless, I am not very optimistic that this will ever be integrated, especially since in long term ReGaHss will be completely replaced by something else coming with a modern programming interface.
Support for procedural programming in HM script would significantly improve the creation and traceability of complex HM scripts. Many existing HM scripts would lose size drastically.
Suggestions for various extensions:
It should be possible to define local functions in the script so that they can be called later in the script.
Implement a new script command that includes another script file. (This functionality is already used internally in the CCU.) In this way, new functions can be defined globally. A default directory should be defined for such includeable scripts. This allows new script functionality to be installed via AddOns (e.g. the sun position script).
Calling functions from shared objects (.so) is a way of making completely new functions available in HM scripts. New functions, e.g. for accessing sockets or a JSON parser, would be possible. In many cases System.exec could be avoided. Developers could also install shared objects again using the add-on mechanism on the CCU. The support of simple scalar data types (int, double, C string) for passing and returning values would help a lot in the first step. Technically, this could be achieved with the help of existing FFI libraries (foreign function interface).