Thanks for sharing. I believe others have developed similar pre-parsers but I don’t think anyone has posted on yet.
Some comments, mainly for future readers who come along later:
-
Be aware that the ability to use libraries and reusable code is one of the drivers behind the creation of the Experimental Rules Engine. There is also the JSR223 add-on that lets you write Rules using Jython, JavaScript, or Groovy. So if one truely wants all the features of a general purpose programming language instead of some of the designed in limitations of the Rules DSL they can use either of these.
-
There is also support for Scripts, though they have a limitation that you cannot pass values into the script which greatly reduces their utility.
-
There used to be a problem with having global variables of the same name in multiple rules files. I don’t know if this is still the case. However, there is absolutely a problem with having Rules with the same name so this script would not work to include whole Rules unless you edit the .rules files after the include.
-
One can often avoid the need to do includes like this at all by organizing your Rules by function rather than location (e.g. have lighting.rules rather than bedroom.rules). For cross-cutting concerns like alerting or calculating time of day you can add in Design Pattern: Separation of Behaviors which centralizes all that logic into one set of Rules, again aleviating the need for performing includes like this.