You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2025/08/28 06:48:14 UTC
[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
Re: AW: [DISCUSS] introduce an explicit field type for parser arguments?
Posted by Sebastian Rühl <sr...@apache.org>.
+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 <ch...@c-ware.de>
> Datum: Donnerstag, 28. August 2025 um 08:48
> An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> 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
>
AW: AW: [DISCUSS] introduce an explicit field type for parser arguments?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Lukasz,
So Sebastian and I have already implemented two of the 4 things:
*
State field
*
Constants type
I’ll try to jump on the other two as soon as I’ve reached a stable point with my new code-gen/spi stuff.
Chris
Von: Łukasz Dywicki <lu...@code-house.org>
Datum: Freitag, 5. September 2025 um 17:39
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: Re: AW: [DISCUSS] introduce an explicit field type for parser arguments?
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 <ch...@c-ware.de>
> Datum: Donnerstag, 28. August 2025 um 08:48
> An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> 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
>
Re: AW: [DISCUSS] introduce an explicit field type for parser arguments?
Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <ch...@c-ware.de>
> Datum: Donnerstag, 28. August 2025 um 08:48
> An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> 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
>
AW: [DISCUSS] introduce an explicit field type for parser arguments?
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ch...@c-ware.de>
Datum: Donnerstag, 28. August 2025 um 08:48
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
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