Nothing would change here … we would just pass in one context instead of some of the fields we’re currently passing in. Stuff like the ReadBuffer and the WriteBuffer etc. It’s more syntactic sugar. Right now, I use ThreadLocals to pass along stuff like the “_curItem”, “_lastItem” etc. I would just move that into a Context type pretty much the same way it’s done in Golang (and how I implemented it in C too)
Chris From: Łukasz Dywicki <[email protected]> Date: Monday, 20. February 2023 at 17:15 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Handling of ByteEncoding in Parser and Serializer? Hey Chris, How does this apply to "with" encoding options Sebastian and you worked on before? I guess that in such case, if we speak of modbus and application level byte encoding, it might be more of runtime setting which could be passed through connection options and propagated down to generated code. Since it is resolved at runtime we would not need to allocate additional fields and rely on connection/runtime context and request byte order from there.. if possible. Cheers, Łukasz On 18.02.2023 17:48, Christofer Dutz wrote: > Hi all, > > so in general we have the situation in which we usually have either BigEndian > or LittleEndian encoding. Or we have dynamic encoding based on data in the > packet itself (PROFINET). Now Ben added something I think we’ll be needing on > other drivers too (Modbus) … that the encoding is passed in from the outside. > > He solved this by passing in a custom type to the Parser and relying on this > being saved in an artificial ParserArgument-Field. > > I’m not a big fan of storing parser arguments in fields to be able to access > them when serializing, because it sort of adds clutter to the model. > > I would love to change things in a way, that if a parser argument of type > “ByteEncoding” is defined, that this field is also automatically added to the > serializer. > > What do you folks think? > > Chris > >
