Hello, Good, we seem to converge :)
Dave Mielke, le dim. 09 mai 2021 13:03:40 -0400, a ecrit: > [quoted lines by Samuel Thibault on 2021/05/09 at 13:01 +0200] > >Really, the original intent was a straightforward: > > > >- if isArray = False, there is just one scalar value to return > >- if isArray = True, there is possibly different values to return, and > > thus use whatever suits best the language (list, array, tuple) to > > convey the values, even if there is just one value. > >- if count != 0 (only valid for isArray = True), the number of values > > being returned is always equal to that count. > > Okay. The bit about count actually being meanless when isArray is false > should probably be formally documented. Yes. > Or, we could change count to something more intuitively obvious like > arraySize. We can rename the field, yes. That breaks the API but not the ABI and I don't think the API break will really pose problem in practice. I'm also thinking that we could as well just squash the fields isArray and hasSubparam into a flags field, since we also want to add can_read and can_write, and possibly others in the future. We can make it a 16bit field and make isarray bit 0 and hasubparam bit 8. That copes with ABI compatibility on little-endian platforms, which is probably all that we really care about concerning any potential use of brltty 6.3. Samuel _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
