Hello Christofer,
I think these proposals will clarify a lot of state handling we had
spread across drivers due to inability to propagate context during the
parsing time. Maybe we will be able to even get some of encryption stuff
utilize that? :)
Great to see these ideas. Only one concern is to keep these compile
time, so we can assure that what we generate from mspec does not refer
unknown/mistaken globals.
Kind regards,
Łukasz
On 8/28/25 12:20, 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
