Hi all, I just had a short call with Sebastian.
I’d like to propose 4 things: * Introduce a field type „state“ which is syntactically similar to „virtual“ fields. However, is backed by a property. This would eliminate the need for the „generate-fields-for-parser-arguments“. * Introduce a new top-level construct: „globals“ where you define properties, which need to be passed to the parser and serialized and are globally available to all levels during parsing and can be accessed via patterns such as „globals.someGlobalProperty“ * Introduce a new top-level construct: „context“ where you define properties, which need to be passed to the parser and serialized and are globally available to all levels during parsing and can be accessed via patterns such as „globals.someGlobalProperty“ (In general this is pretty much the same as globals, however is used to carry request context and not global context * Introduce a new top-level construct „constants“ which would generate types that only have „const“ fields … currently we’re mis-using simple types for this, but they have parsers, serializers getLenghtInBits/Bytes and constructors, which we actually don’t need. What do you think? Chris Von: Christofer Dutz <[email protected]> Datum: Donnerstag, 28. August 2025 um 08:48 An: [email protected] <[email protected]> Betreff: [DISCUSS] introduce an explicit field type for parser arguments? Hi all, While working on implementing a new java code gen based on JavaPoet I came across one thing that I’m not really happy with. In BacNet, c-bus, eip and Profinet to we use the „generate-properties-for-parser-arguments“ option in the code generation, which makes parser arguments available as properties. This does solve the problem in a hand full of cases. However, does it make the code quite ugly. I was thinking of introducing a new field type „argument“ which you would simply give a „name" and it would take the parser arguments type information and only output such a field where needed. This would clean up things and not have these artificial properties generated EVERYWHERE (currently they are generated in the parent as well as the children) What do you think? Chris
