The more I think of it, the more I come to the conclusion that I should just use "const" fields and only model real fields for the actual information. This dramatically reduces the memory footprint of the model and simplifies working with objects as all you have are some simple properties like "subscriberProcessIdentifier" and don't need to construct or navigate through 2 additional object layers.
It is some more work in modeling the spec but copy +paste is my friend 😉 Chris Holen Sie sich Outlook für Android<https://aka.ms/ghei36> ________________________________ From: Christofer Dutz <christofer.d...@c-ware.de> Sent: Saturday, September 21, 2019 4:10:34 PM To: dev@plc4x.apache.org <dev@plc4x.apache.org> Subject: [CODEGEN] Some thoughts "restrictions" of types Hi all, In the BACnet protocol I encountered something new (Who would have thought?) Here sort of everything is encoded with so called Tags. These have a fixed structure and a variable payload. Now depending on the type of request there are fixed sequences of tags coming in. So the first Tag has meaning X, the seconds Y, … The thing is I would like to sort of say: Here comes a Tag, but with fixed portions set to certain values. So let’s take the BACnetTag definition: [discriminatedType 'BACnetTag' [simple uint 4 'typeOrTagNumber'] [discriminator uint 1 'contextSpecificTag'] [simple uint 3 'lengthValueType'] … ] And a the following request: ['0x05' BACnetConfirmedServiceRequestSubscribeCOV [simple BACnetTag 'subscriberProcessIdentifier'] [simple BACnetTag 'monitoredObjectIdentifier'] [simple BACnetTag 'issueConfirmedNotifications'] [simple BACnetTag 'lifetime'] ] It is not 100% correct, because I am expecting a tag with: Type = 0 Context = 1 Length = 1 Which 1-byte payload is treated as 'subscriberProcessIdentifier' So I sort of need to come up with a notation for this … any ideas? Chris
