...

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.

Naming "endianess" "byte order"

It seems that we should name the attribute "byte order" instead of "endianess".

Cleaning up the string types

...

Also could we use the attribute concept sebastian for the endianess for the encoding. So the default would be UTF-8, but it could be changed with "encoding='UTF-16'".

Cleaning up the way we handle Encodings

Right now we only used "encoding" settings for string fields, however this is not 100% correct. For other places we just implicitly defined them. For example for float we have the "float 8.23" and "float 11.52" this actually defines two different encodings. So we'll change this to "float 32" and "float 64" which defaults to IEEE floating point encoding. 

Cleaning up the code-generation

Especially for Java the templates have been becoming more and more complex. Especially when we would be adding all of the "byte order setting" this would become quite unmaintainable.

The idea was to create a set of static functions, that can be imported with static imports, that handle the logic for the different types of fields have.

Every field method would have the individual read/write operation as first argument, followed by all the mandatory pieces of information.

Optional attributes would be passed with var-arg parameters at the end. 

    // simple type case
    lalala = readOptionalField("lalala",  dataReaderUnsignedInt( ....), something == true)

    // Enum type case // TODO: magic trick is to use the function pointer of the enum parse static method
    lalala = readOptionalField("lalala", enumReader(TypeOfHurz::enumForValue, dataReaderUnsignedIntCreatorDingels( ... readBuffer ....)),  something == true, withAdditonasdl(), withEncoding(), withFickiciy())

    // Complex type case // TODO: magic trick is to use a supplier lambda for the staticParse
    lalala = readOptionalField("lalala", complexTypeReader(()->TypeOfHurz.staticParseIwas(readBuffer, asdasdasdasd, asdasd), readBuffer),  something == true)
    

Cleaning up the way params are passed to types

In General we decided to replace the square bracets around the passing of parameters from one type to the other with round bracets. This makes the syntax a bit more similar to normal programming languages.

We also moved the place where params are passed from the end to directly after the complex type name.