Page History

...

With adding a flag to a type: This seems simple, but how would we control this from the usage?

Chris'

...

thoughts on this

In all cases we would simply make the "endianess" setting in the ReadBuffer and WriteBuffer writable. So we can simply read the endianess settings a buffer currently has and we can change this. This would not require us to copy and duplicate the datastructures and waste memory. Reading BE or LE has absolutely no impact on how the read/write-position is updated ... it simply controlls if the read values are returned in an inverted byte order. So it should not have any memory or performance impact, even if we keept toggling endianess after every field we read.

...

If the type definition doesn't have any BE/LE flags, it simply uses the endianess of the parent.

Sebastian' thougths on this

We can support all three cases:

1. For the endianess I would implement this as a generic `batchSetAttribute` e.g.
   [batchSetAttribute endianess='integerEncoding == IntegerEncoding.BIG_ENDIAN'
  [simple sometype field1...]
  [simple sometype field2...]
  [simple sometype field3...]
  [simple sometype field4...]
]
2. For the field it would have the same attribute as in 1
   [simple sometype field1... endianess='integerEncoding == IntegerEncoding.BIG_ENDIAN']
3. This would be like any other type arg to me

Defining it this way it would be future-proof, robust and re-useable for other attributes. Additionally I would (a discussed ages ago) define a top-level element for endianess in the mspec to make it part of the definition.