Closed hclbaur closed 2 months ago
Instead of keeping a map <String, Object> in the statement context we can keep <String, Value> where Value is a class holding the Object bound to the variable, but also a flag indicating whether the value is mutable (spoiler: params are not).
Another and simpler approach is to register params as variables with "p:" namespace prefix, so they are distinct from regular variables, Due to the prefix they cannot be redeclared in subsequent variable statements.
Also possible is to just catch this situation in the parser and reject it. This is by far the easiest fix. Of course, it will still be possible to create invalid transforms by manually assembling statements. To fix this we need to harden the API, for which I will create another issue (#14 ).
As of 1.3.1 the SDT parser checks for conflicts between params and variables.
This will throw be.baur.sdt.TransformException: error at /Transform/VariableStatement[2]: addressbook2.sda (The system cannot find the file specified).
Although a parameter cannot be redeclared, it can be overwritten because no distinction is made between existing parameters and variables.