+1 - Sebastian
On 2025/08/28 08:20:52 Christofer Dutz wrote: > 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 >
