I implemented a new data structure
ExprCodeGeneratorResult that collects information while generating code for expressions. It encapsulates parts of the expression in new methods during the analysis of the expression tree. It returns this information back to the caller of
ExprCodeGenerator such that the caller can include these additional methods. (
ExprCodeGenerator itself is not handling the actual file content, so cannot directly write the methods to file once it creates a new one.)
The current implementation solves the problem in #611 (closed). For the model SupConnectTwo.cif, it generates Aut_sup.java, which can be sucessfully parsed. Furthermore, the current changes still pass all original test cases.
I would like to get some feedback on this idea, hence the draft labeling. Some things to take into account.
- Only the guard code generation takes the new data structure correctly into account. Other places that call methods from
ExprCodeGeneratordon't do it fully correctly (as long as no method for a sub expression is generated, it works fine). If the approach is fine, I will adjust these other calls as well.
- The generation of the new methods code might possibly be also done in the new class
ExprCodeGeneratorResult. The caller of methods in
ExprCodeGeneratorthan only need to insert these new methods in the right place in their files.
- If more than two
ExprCodeGeneratorResultobjects are to be merge, the check whether they together exceed the limit is done only after merging them (and thus only a single new method will be created). Maybe if a subset of them already exceed the limit, they should already be encapsulated by a new method before continuoing with the merge.
- The current limit is not optimized. For the model above, it works with
limit = 1,000, but not with
limit = 10,000.
- Originally, when the evaluation of a guard fails during run-time, an exception is thrown that includes the full guard. This is also not possible for very long guards (you will get a
static string is too longerror). What would be a good alternative exception text that can indicate which guard causes the problem.
- No new test case is yet included.
Best reviewed per commit, but some later commits fix some problems though.
Closes #611 (closed)