Yeah, I had this situation multiple times in the past, but it was only one or two types. With open-protocol, every type of message (0000-9999) can have 00-99 revisions. So, I just thought …. Better implement this instead of defining all the needed intermediate types.
Chris From: Łukasz Dywicki <[email protected]> Date: Friday, 27. January 2023 at 12:55 To: [email protected] <[email protected]> Subject: Re: [NOTICE] Updated Code-Generation .... 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 > > > >
