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 <l...@code-house.org> Date: Monday, 6. February 2023 at 12:21 To: dev@plc4x.apache.org <dev@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 <cesar.gar...@ceos.com.ve> > Sent: Saturday, February 4, 2023 6:47:54 PM > To: dev@plc4x.apache.org <dev@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 (<christofer.d...@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.automat...@siemens.com > <support.aan.automat...@siemens.com>* >
