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 2023/02/04 10:18:41 UTC
[DISCUSS] Generally move to using "Context" objects inside our generated code?
Hi all,
recently I have been working on supporting dynamic tags like “_itemCount”, “_curItem” and “_lastItem” in array elements.
In java I used ThreadLocals for this as it felt like a Java-Native way and it wouldn’t blow up the signatures of our Parser, Serializer and GetLengthInXYZ methods.
Now when looking for something similar in Go, it seems in such cases Contexts are used. These are sort of like a HashMap wrapped with little util methods. In this HashMap you pass along values that are “in context” … if you change the context, a copy of the old context is created and then the updated/added values are updated/added to the HashMap.
So, in an array I add the additional information to the existing one by:
arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems), int(_curItem))
and then simply pass in the „arrayContext”. And for accessing it I simply for this:
spiContext.GetLastItemFromContext(ctx)
Admittedly I’m not a big fan of crating copies of the full context every time, I would prefer to be able to push to sort of a context stack, but I guess that’s the way things work in Go.
When I wanted to add the functionality of Java and Go to PLC4C I was a bit stuck, as neither concept really existed.
However thinking a bit more about it, adding the concept of Contexts to C was actually quite simple.
Now that got me thinking:
Shouldn’t we implement the same pattern for Java? It should be easy to implement.
And while I was thinking, I even thought: Shouldn’t we extend this idea and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and anything we’re currently passing along with “WithXYZOption” var-args, into these Contexts and simply pass along one Context object?
I think this would clean up the code quite a bit.
What do you think?
Chris
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Lukas Ott <ot...@gmail.com>.
+1 yes Otto s comment is correct so it seems to be the next logical step.
Otto Fowler <ot...@gmail.com> schrieb am Sa., 4. Feb. 2023, 15:42:
> Any DSL at some point will consider stack / call / variable contexts.
> This seems reasonable.
>
> From: Christofer Dutz <ch...@c-ware.de>
> <ch...@c-ware.de>
> Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
> Date: February 4, 2023 at 05:18:59
> To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
> Subject: [DISCUSS] Generally move to using "Context" objects inside our
> generated code?
>
> Hi all,
>
> recently I have been working on supporting dynamic tags like “_itemCount”,
> “_curItem” and “_lastItem” in array elements.
>
> In java I used ThreadLocals for this as it felt like a Java-Native way and
> it wouldn’t blow up the signatures of our Parser, Serializer and
> GetLengthInXYZ methods.
>
> Now when looking for something similar in Go, it seems in such cases
> Contexts are used. These are sort of like a HashMap wrapped with little
> util methods. In this HashMap you pass along values that are “in context” …
> if you change the context, a copy of the old context is created and then
> the updated/added values are updated/added to the HashMap.
>
> So, in an array I add the additional information to the existing one by:
>
> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
> int(_curItem))
>
>
> and then simply pass in the „arrayContext”. And for accessing it I simply
> for this:
>
> spiContext.GetLastItemFromContext(ctx)
>
>
>
> Admittedly I’m not a big fan of crating copies of the full context every
> time, I would prefer to be able to push to sort of a context stack, but I
> guess that’s the way things work in Go.
>
>
>
> When I wanted to add the functionality of Java and Go to PLC4C I was a bit
> stuck, as neither concept really existed.
>
>
>
> However thinking a bit more about it, adding the concept of Contexts to C
> was actually quite simple.
>
>
>
> Now that got me thinking:
>
> Shouldn’t we implement the same pattern for Java? It should be easy to
> implement.
>
>
>
> And while I was thinking, I even thought: Shouldn’t we extend this idea and
> also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
> anything we’re currently passing along with “WithXYZOption” var-args, into
> these Contexts and simply pass along one Context object?
>
> I think this would clean up the code quite a bit.
>
>
>
> What do you think?
>
>
>
> Chris
>
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Otto Fowler <ot...@gmail.com>.
Any DSL at some point will consider stack / call / variable contexts.
This seems reasonable.
From: Christofer Dutz <ch...@c-ware.de>
<ch...@c-ware.de>
Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Date: February 4, 2023 at 05:18:59
To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Subject: [DISCUSS] Generally move to using "Context" objects inside our
generated code?
Hi all,
recently I have been working on supporting dynamic tags like “_itemCount”,
“_curItem” and “_lastItem” in array elements.
In java I used ThreadLocals for this as it felt like a Java-Native way and
it wouldn’t blow up the signatures of our Parser, Serializer and
GetLengthInXYZ methods.
Now when looking for something similar in Go, it seems in such cases
Contexts are used. These are sort of like a HashMap wrapped with little
util methods. In this HashMap you pass along values that are “in context” …
if you change the context, a copy of the old context is created and then
the updated/added values are updated/added to the HashMap.
So, in an array I add the additional information to the existing one by:
arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
int(_curItem))
and then simply pass in the „arrayContext”. And for accessing it I simply
for this:
spiContext.GetLastItemFromContext(ctx)
Admittedly I’m not a big fan of crating copies of the full context every
time, I would prefer to be able to push to sort of a context stack, but I
guess that’s the way things work in Go.
When I wanted to add the functionality of Java and Go to PLC4C I was a bit
stuck, as neither concept really existed.
However thinking a bit more about it, adding the concept of Contexts to C
was actually quite simple.
Now that got me thinking:
Shouldn’t we implement the same pattern for Java? It should be easy to
implement.
And while I was thinking, I even thought: Shouldn’t we extend this idea and
also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
anything we’re currently passing along with “WithXYZOption” var-args, into
these Contexts and simply pass along one Context object?
I think this would clean up the code quite a bit.
What do you think?
Chris
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
well … what I could do (after getting all tests on all languages working again), would be to add the Context concept to the Java version, as this is the last one not supporting that.
I would then also change all to use contexts for passing along the ReadBuffer and WriteBuffer as well as the Encoding and ByteOrder. Things like the parser arguments we should probably keep the way they are.
Chris
From: Łukasz Dywicki <lu...@code-house.org>
Date: Monday, 6. February 2023 at 12:21
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
I don't think Cesar suggestion is far from Christofer's work.
Making a context which is a glue between information known at compile
time and resolution done at runtime makes a lot of sense, since some
data might depend not only on connection setup but also on extra
resolution done on top of established connection. I could point here
recent work made by Christofer on custom/complex types for ADS which is
known only after making connection and clearly involves wire operations.
Not sure about OPC UA encryption, but from what I remember it was also
something which required a bit of adjustments from Ben.
There are more cases when serialization may require external input which
does not align with connection options or make them insane long. A prime
example could be a WM-Bus where one connection must handle multiple
encryption keys for end device's (and you may have hundreds of them).
If you ask me, getting a concept of context included in generated
serialization library, I'm all for it since it can streamline further
work in multiple areas. I'd suggest to keep it as separate SPI/API
element with known type, cause then it will be much easier to keep track
of its use across multiple places. While Map's are great giving insane
flexibility, tracing their use is extremely hard.
Best,
Łukasz
On 4.02.2023 19:19, Christofer Dutz wrote:
> I'm more talking about a serialization and parse-context. Driver context would be something separate and I think we already have that, don't we?
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Cesar Garcia <ce...@ceos.com.ve>
> Sent: Saturday, February 4, 2023 6:47:54 PM
> To: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
>
> +1, If there's a way to get the driver's context, something like
> "PlcDriver.getContext()", and pass pipe information, interesting.
>
> El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<ch...@c-ware.de>)
> escribió:
>
>> Hi all,
>>
>> recently I have been working on supporting dynamic tags like “_itemCount”,
>> “_curItem” and “_lastItem” in array elements.
>>
>> In java I used ThreadLocals for this as it felt like a Java-Native way and
>> it wouldn’t blow up the signatures of our Parser, Serializer and
>> GetLengthInXYZ methods.
>>
>> Now when looking for something similar in Go, it seems in such cases
>> Contexts are used. These are sort of like a HashMap wrapped with little
>> util methods. In this HashMap you pass along values that are “in context” …
>> if you change the context, a copy of the old context is created and then
>> the updated/added values are updated/added to the HashMap.
>>
>> So, in an array I add the additional information to the existing one by:
>>
>> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
>> int(_curItem))
>>
>>
>> and then simply pass in the „arrayContext”. And for accessing it I simply
>> for this:
>>
>> spiContext.GetLastItemFromContext(ctx)
>>
>>
>>
>> Admittedly I’m not a big fan of crating copies of the full context every
>> time, I would prefer to be able to push to sort of a context stack, but I
>> guess that’s the way things work in Go.
>>
>>
>>
>> When I wanted to add the functionality of Java and Go to PLC4C I was a bit
>> stuck, as neither concept really existed.
>>
>>
>>
>> However thinking a bit more about it, adding the concept of Contexts to C
>> was actually quite simple.
>>
>>
>>
>> Now that got me thinking:
>>
>> Shouldn’t we implement the same pattern for Java? It should be easy to
>> implement.
>>
>>
>>
>> And while I was thinking, I even thought: Shouldn’t we extend this idea
>> and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
>> anything we’re currently passing along with “WithXYZOption” var-args, into
>> these Contexts and simply pass along one Context object?
>>
>> I think this would clean up the code quite a bit.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
>>
>
> --
> *CEOS Automatización, C.A.*
> *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
>
> *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> *Ing. César García*
>
> *Cel: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automation@siemens.com
> <su...@siemens.com>*
>
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Otto Fowler <ot...@gmail.com>.
Why don’t we start with the original parser context, and extend that when
it is working and we have a feel for it?
From: Łukasz Dywicki <lu...@code-house.org> <lu...@code-house.org>
Reply: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Date: February 6, 2023 at 06:21:05
To: dev@plc4x.apache.org <de...@plc4x.apache.org> <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Generally move to using "Context" objects inside
our generated code?
I don't think Cesar suggestion is far from Christofer's work.
Making a context which is a glue between information known at compile
time and resolution done at runtime makes a lot of sense, since some
data might depend not only on connection setup but also on extra
resolution done on top of established connection. I could point here
recent work made by Christofer on custom/complex types for ADS which is
known only after making connection and clearly involves wire operations.
Not sure about OPC UA encryption, but from what I remember it was also
something which required a bit of adjustments from Ben.
There are more cases when serialization may require external input which
does not align with connection options or make them insane long. A prime
example could be a WM-Bus where one connection must handle multiple
encryption keys for end device's (and you may have hundreds of them).
If you ask me, getting a concept of context included in generated
serialization library, I'm all for it since it can streamline further
work in multiple areas. I'd suggest to keep it as separate SPI/API
element with known type, cause then it will be much easier to keep track
of its use across multiple places. While Map's are great giving insane
flexibility, tracing their use is extremely hard.
Best,
Łukasz
On 4.02.2023 19:19, Christofer Dutz wrote:
> I'm more talking about a serialization and parse-context. Driver context
would be something separate and I think we already have that, don't we?
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Cesar Garcia <ce...@ceos.com.ve>
> Sent: Saturday, February 4, 2023 6:47:54 PM
> To: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Subject: Re: [DISCUSS] Generally move to using "Context" objects inside
our generated code?
>
> +1, If there's a way to get the driver's context, something like
> "PlcDriver.getContext()", and pass pipe information, interesting.
>
> El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<ch...@c-ware.de>)
> escribió:
>
>> Hi all,
>>
>> recently I have been working on supporting dynamic tags like
“_itemCount”,
>> “_curItem” and “_lastItem” in array elements.
>>
>> In java I used ThreadLocals for this as it felt like a Java-Native way
and
>> it wouldn’t blow up the signatures of our Parser, Serializer and
>> GetLengthInXYZ methods.
>>
>> Now when looking for something similar in Go, it seems in such cases
>> Contexts are used. These are sort of like a HashMap wrapped with little
>> util methods. In this HashMap you pass along values that are “in
context” …
>> if you change the context, a copy of the old context is created and then
>> the updated/added values are updated/added to the HashMap.
>>
>> So, in an array I add the additional information to the existing one by:
>>
>> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
>> int(_curItem))
>>
>>
>> and then simply pass in the „arrayContext”. And for accessing it I
simply
>> for this:
>>
>> spiContext.GetLastItemFromContext(ctx)
>>
>>
>>
>> Admittedly I’m not a big fan of crating copies of the full context every
>> time, I would prefer to be able to push to sort of a context stack, but
I
>> guess that’s the way things work in Go.
>>
>>
>>
>> When I wanted to add the functionality of Java and Go to PLC4C I was a
bit
>> stuck, as neither concept really existed.
>>
>>
>>
>> However thinking a bit more about it, adding the concept of Contexts to
C
>> was actually quite simple.
>>
>>
>>
>> Now that got me thinking:
>>
>> Shouldn’t we implement the same pattern for Java? It should be easy to
>> implement.
>>
>>
>>
>> And while I was thinking, I even thought: Shouldn’t we extend this idea
>> and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder
and
>> anything we’re currently passing along with “WithXYZOption” var-args,
into
>> these Contexts and simply pass along one Context object?
>>
>> I think this would clean up the code quite a bit.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
>>
>
> --
> *CEOS Automatización, C.A.*
> *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
>
> *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> *Ing. César García*
>
> *Cel: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automation@siemens.com
> <su...@siemens.com>*
>
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Łukasz Dywicki <lu...@code-house.org>.
I don't think Cesar suggestion is far from Christofer's work.
Making a context which is a glue between information known at compile
time and resolution done at runtime makes a lot of sense, since some
data might depend not only on connection setup but also on extra
resolution done on top of established connection. I could point here
recent work made by Christofer on custom/complex types for ADS which is
known only after making connection and clearly involves wire operations.
Not sure about OPC UA encryption, but from what I remember it was also
something which required a bit of adjustments from Ben.
There are more cases when serialization may require external input which
does not align with connection options or make them insane long. A prime
example could be a WM-Bus where one connection must handle multiple
encryption keys for end device's (and you may have hundreds of them).
If you ask me, getting a concept of context included in generated
serialization library, I'm all for it since it can streamline further
work in multiple areas. I'd suggest to keep it as separate SPI/API
element with known type, cause then it will be much easier to keep track
of its use across multiple places. While Map's are great giving insane
flexibility, tracing their use is extremely hard.
Best,
Łukasz
On 4.02.2023 19:19, Christofer Dutz wrote:
> I'm more talking about a serialization and parse-context. Driver context would be something separate and I think we already have that, don't we?
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Cesar Garcia <ce...@ceos.com.ve>
> Sent: Saturday, February 4, 2023 6:47:54 PM
> To: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
>
> +1, If there's a way to get the driver's context, something like
> "PlcDriver.getContext()", and pass pipe information, interesting.
>
> El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<ch...@c-ware.de>)
> escribió:
>
>> Hi all,
>>
>> recently I have been working on supporting dynamic tags like “_itemCount”,
>> “_curItem” and “_lastItem” in array elements.
>>
>> In java I used ThreadLocals for this as it felt like a Java-Native way and
>> it wouldn’t blow up the signatures of our Parser, Serializer and
>> GetLengthInXYZ methods.
>>
>> Now when looking for something similar in Go, it seems in such cases
>> Contexts are used. These are sort of like a HashMap wrapped with little
>> util methods. In this HashMap you pass along values that are “in context” …
>> if you change the context, a copy of the old context is created and then
>> the updated/added values are updated/added to the HashMap.
>>
>> So, in an array I add the additional information to the existing one by:
>>
>> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
>> int(_curItem))
>>
>>
>> and then simply pass in the „arrayContext”. And for accessing it I simply
>> for this:
>>
>> spiContext.GetLastItemFromContext(ctx)
>>
>>
>>
>> Admittedly I’m not a big fan of crating copies of the full context every
>> time, I would prefer to be able to push to sort of a context stack, but I
>> guess that’s the way things work in Go.
>>
>>
>>
>> When I wanted to add the functionality of Java and Go to PLC4C I was a bit
>> stuck, as neither concept really existed.
>>
>>
>>
>> However thinking a bit more about it, adding the concept of Contexts to C
>> was actually quite simple.
>>
>>
>>
>> Now that got me thinking:
>>
>> Shouldn’t we implement the same pattern for Java? It should be easy to
>> implement.
>>
>>
>>
>> And while I was thinking, I even thought: Shouldn’t we extend this idea
>> and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
>> anything we’re currently passing along with “WithXYZOption” var-args, into
>> these Contexts and simply pass along one Context object?
>>
>> I think this would clean up the code quite a bit.
>>
>>
>>
>> What do you think?
>>
>>
>>
>> Chris
>>
>>
>>
>>
>>
>>
>
> --
> *CEOS Automatización, C.A.*
> *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
> *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
>
> *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
> *Ing. César García*
>
> *Cel: +58 414-760.98.95*
>
> *Hotline Técnica SIEMENS: 0800 1005080*
>
> *Email: support.aan.automation@siemens.com
> <su...@siemens.com>*
>
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Christofer Dutz <ch...@c-ware.de>.
I'm more talking about a serialization and parse-context. Driver context would be something separate and I think we already have that, don't we?
Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
________________________________
From: Cesar Garcia <ce...@ceos.com.ve>
Sent: Saturday, February 4, 2023 6:47:54 PM
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
+1, If there's a way to get the driver's context, something like
"PlcDriver.getContext()", and pass pipe information, interesting.
El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<ch...@c-ware.de>)
escribió:
> Hi all,
>
> recently I have been working on supporting dynamic tags like “_itemCount”,
> “_curItem” and “_lastItem” in array elements.
>
> In java I used ThreadLocals for this as it felt like a Java-Native way and
> it wouldn’t blow up the signatures of our Parser, Serializer and
> GetLengthInXYZ methods.
>
> Now when looking for something similar in Go, it seems in such cases
> Contexts are used. These are sort of like a HashMap wrapped with little
> util methods. In this HashMap you pass along values that are “in context” …
> if you change the context, a copy of the old context is created and then
> the updated/added values are updated/added to the HashMap.
>
> So, in an array I add the additional information to the existing one by:
>
> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
> int(_curItem))
>
>
> and then simply pass in the „arrayContext”. And for accessing it I simply
> for this:
>
> spiContext.GetLastItemFromContext(ctx)
>
>
>
> Admittedly I’m not a big fan of crating copies of the full context every
> time, I would prefer to be able to push to sort of a context stack, but I
> guess that’s the way things work in Go.
>
>
>
> When I wanted to add the functionality of Java and Go to PLC4C I was a bit
> stuck, as neither concept really existed.
>
>
>
> However thinking a bit more about it, adding the concept of Contexts to C
> was actually quite simple.
>
>
>
> Now that got me thinking:
>
> Shouldn’t we implement the same pattern for Java? It should be easy to
> implement.
>
>
>
> And while I was thinking, I even thought: Shouldn’t we extend this idea
> and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
> anything we’re currently passing along with “WithXYZOption” var-args, into
> these Contexts and simply pass along one Context object?
>
> I think this would clean up the code quite a bit.
>
>
>
> What do you think?
>
>
>
> Chris
>
>
>
>
>
>
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automation@siemens.com
<su...@siemens.com>*
Re: [DISCUSS] Generally move to using "Context" objects inside our generated code?
Posted by Cesar Garcia <ce...@ceos.com.ve>.
+1, If there's a way to get the driver's context, something like
"PlcDriver.getContext()", and pass pipe information, interesting.
El sáb, 4 feb 2023 a las 6:18, Christofer Dutz (<ch...@c-ware.de>)
escribió:
> Hi all,
>
> recently I have been working on supporting dynamic tags like “_itemCount”,
> “_curItem” and “_lastItem” in array elements.
>
> In java I used ThreadLocals for this as it felt like a Java-Native way and
> it wouldn’t blow up the signatures of our Parser, Serializer and
> GetLengthInXYZ methods.
>
> Now when looking for something similar in Go, it seems in such cases
> Contexts are used. These are sort of like a HashMap wrapped with little
> util methods. In this HashMap you pass along values that are “in context” …
> if you change the context, a copy of the old context is created and then
> the updated/added values are updated/added to the HashMap.
>
> So, in an array I add the additional information to the existing one by:
>
> arrayCtx := spiContext.CreateArrayContext(ctx, int(_numItems),
> int(_curItem))
>
>
> and then simply pass in the „arrayContext”. And for accessing it I simply
> for this:
>
> spiContext.GetLastItemFromContext(ctx)
>
>
>
> Admittedly I’m not a big fan of crating copies of the full context every
> time, I would prefer to be able to push to sort of a context stack, but I
> guess that’s the way things work in Go.
>
>
>
> When I wanted to add the functionality of Java and Go to PLC4C I was a bit
> stuck, as neither concept really existed.
>
>
>
> However thinking a bit more about it, adding the concept of Contexts to C
> was actually quite simple.
>
>
>
> Now that got me thinking:
>
> Shouldn’t we implement the same pattern for Java? It should be easy to
> implement.
>
>
>
> And while I was thinking, I even thought: Shouldn’t we extend this idea
> and also get the ReadBuffer, WriteBuffer, the Encoding, the ByteOrder and
> anything we’re currently passing along with “WithXYZOption” var-args, into
> these Contexts and simply pass along one Context object?
>
> I think this would clean up the code quite a bit.
>
>
>
> What do you think?
>
>
>
> Chris
>
>
>
>
>
>
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,*
*PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing. César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automation@siemens.com
<su...@siemens.com>*