So, I just took the time to evaluate the results of my LinkedIn question. There were 25 people voting and I think we can make 96% of all people happy with this:
The array notation is: [lower-bound .. upper-bound] = “[2..5]” However, it should still be possible to enter something like this: “[5]” but we internally interpret that as [0..4] With my multi-dimensional array question, things were not quite as simple ;-) It is the IEC notation to write them as: [1...3, 4...5], however more people voted for [1...3][4...5] I was expecting the people voting for the IEC option to be more OT guys and the other to be IT guys, but I couldn’t really spot that pattern. Here I would opt for going with the majority and use the [1...3][4...5] notation. However, should the parser be able to also read [1...3, 4...5]. What do you think? Would that be a good way to go? Chris Von: Jinlin Hong <myhongjin...@gmail.com> Datum: Donnerstag, 6. Februar 2025 um 09:07 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: Re: [DISCUSS] Streamline the address format over all drivers Thank you for your reply, and my apologies for mixing up the bit and array discussions. Regarding the array syntax, I think it’s great to allow users to customize the return format. That said, [5] and [4][6] do indeed represent the same thing, haha. Jinlin Christofer Dutz <christofer.d...@c-ware.de> 於 2025年2月6日 �L四 下午3:19��道： > Replying to both in one email here. > > Regarding the array notation: > I am proposing to use one format. So if you have a tag and ask it to > return the string representation, you'll only get one format. > > I'm more proposing to make the parser a bit more flexible and support more > options as input to allow some OT engineering addresses parsable without > having to reformat all addresses. > > > I think the bit stuff is a completely different discussion. Happy to do > this in parallel... Let's stick to arrays in this discussion ;-) > > Chris > > > Gesendet von Outlook für Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Jinlin Hong <myhongjin...@gmail.com> > Sent: Thursday, February 6, 2025 2:50:34 AM > To: dev@plc4x.apache.org <dev@plc4x.apache.org> > Subject: Re: [DISCUSS] Streamline the address format over all drivers > > We have previously discussed this, and some of the conclusions might no > longer apply: Cleanup of how we handle all the bit-related fields > < > https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields > >. > In my opinion, regardless of the final rules, we just need to finalize it. > > Christofer Dutz <christofer.d...@c-ware.de> 於 2025年2月5日 �L三 下午2:27��道： > > > Hi all > > > > I’m playing a bit with my UI thingy and am currently implementing some > Tag > > editor. > > > > I have inputs for the address string, the type name as well as the > > array-info and I need to generate the full address string for all drivers > > from these fragments. > > > > Currently it seems not all drivers follow the same structure. > > > > I did a survey on LinkedIn on the various aspects of how array-notations > > could be processed. > > > > Even if the survey is not over yet, it does look as if the following > seems > > to align with most people: > > > > [2..5] implicates elements 2,3,4,5 > > [2..5, 6..9] is a multi-dimensional array > > > > Ideally, we should probably also understand things like, but when > > serializing we should use above notations: > > > > [5] is a shorthand for elements 0, 1, 2, 3, 4 > > [4][6] (A more IT-like array definition) > > > > Now for integrating things in other tools, I think it would be good if > all > > address strings had the following structure (similar to how our > connection > > strings work) > > > > {protocol-dependent-address}:{typename}{[array-syntax]}{options} > > > > The type-name could be omitted for protocols such as ADS where the > address > > already defines the type. > > In that case we should probably also have API types for accessing these > > parts of the addresses. > > > > What do you think? > > > > Chris > > > > > > > > > > And for STRING and WSTRING to also have optional string-lengths in round > > brackets behind the STRING or WSTRING. > > > > What do you think? > > > > Chris > > >
