Hey Chris & Sebastian,
That's a great addition cause I've ran into parser issues while trying
to extend ADS mspec. My trouble was a frame with error code which lead
to a nested type switch.
For proof of concept I moved typeSwitch to another discriminatedType
which worked, but caused a massive change to the generated code and
logic of drivers.
Looking at your example I have a new hope that amount of changes can be
reduced. :-)
Kind regards,
Łukasz
On 27.01.2023 12:48, Christofer Dutz wrote:
Hi all,
I guess most people won’t care about this, but for anyone writing MSPECs, this
is HUGE.
Sebastian and I implemented some changes to mspec and the Java code-generation
that now allow using typeSwitch fields inside cases of typeSwitches.
This allows multiple layers of polymorphism.
Here our example mspec that we tested with:
[discriminatedType TypeSwitchInTypeSwitchParentType
[discriminator uint 8 typeNumber]
[simple uint 8 parentFieldHurz]
[typeSwitch typeNumber
['0x00' *Child0
[discriminator uint 8 childNumber]
[simple uint 8 childFieldwolf]
[typeSwitch childNumber
['0x01' *Infant0
[discriminator uint 8 infantNumber]
[simple uint 8 infantSomeField00]
[typeSwitch infantNumber
['0x98' *InfantsChild0
[simple uint 8 infantsChild0SomeField00]
]
['0x99' *InfantsChild1
[simple uint 8 infantsChild1SomeField00]
]
]
]
['0x02' *Infant1
[simple uint 8 infantSomeField01]
]
['0x03' *Infant2
[simple uint 8 infantSomeField02]
]
]
]
['0x10' *Child1
[discriminator uint 8 childNumber]
[simple uint 8 childFieldLamm]
[typeSwitch childNumber
['0x11' *Infant3
[simple uint 8 infantSomeField1ß]
]
['0x12' *Infant4
[simple uint 8 infantSomeField11]
]
['0x13' *Infant5
[simple uint 8 infantSomeField12]
]
]
]
['0x20' *Child2
[discriminator uint 8 childNumber]
[simple uint 8 childFieldGrueneWiese]
[typeSwitch childNumber
['0x21' *Infant6
[simple uint 8 infantSomeField21]
]
['0x22' *Infant7
[simple uint 8 infantSomeField22]
]
['0x23' *Infant8
[simple uint 8 infantSomeField23]
]
]
]
]
]
While working on the code-gen and fixing some issues with a new protocol I’m
working on, I noticed that we were generating unneeded properties into our
types, that required us to set some dummy values.
I’ve changed this that this no longer is needed but can be switched on via
code-generation options.
<configuration>
<protocolName>c-bus</protocolName>
<languageName>java</languageName>
<outputFlavor>read-write</outputFlavor>
<outputDir>src/main/generated</outputDir>
<options>
<generate-properties-for-parser-arguments>true</generate-properties-for-parser-arguments>
<!-- We want properties that contain the values of reserved fields, if the
value differs from the expected one -->
<generate-properties-for-reserved-fields>true</generate-properties-for-reserved-fields>
</options>
</configuration>
I’ve also removed the dummy values from the drivers in all drivers except c-bus
and bacnet.
Still doing the last tweaks but hope to be able to push soon.
So far the update :-)
Chris
