SBE Flyweight type assumption errors

[kdkavanagh]

SBE flyweights make assumptions about header field types. Related to #629

sbeSchemaId() in x.y.z.EventBlotEncoder cannot implement sbeSchemaId() in org.agrona.sbe.Flyweight
[ERROR]   return type short is not compatible with int

[kdkavanagh]

Since the flyweights are statically defined in Agrona, one option is to cast to an int inside the generated code so that it always matches the flyweight.

Another option would be to move the flyweights inside SBE itself and dynamically generate them.

I can take a stab at either approach, the first seems quicker/easier, but will await guidance from you guys

[tmontgomery]

I would say to cast an int for now (same with the other fields in the header such as sbeSchemaVersion and what is in MessageFlyweight). This is only used when generating interfaces for codecs.

[mjpt777]

To build with not standard types for the header should be done carefully. It makes OTF and any sort of standardisation difficult. I think it was a mistake that the spec allows this to change. The standard approach results in a header that is 8 byte aligned which is good.

However if a different approach is to be taken I think a custom generator should be used to indicate that the standard Agrona headers do not apply and different code should be generated. The suggested approach is only partial. What if the type was larger than int?

[kdkavanagh]

Generally agree. Let me think about what kinds of alternatives might exist and/or what warnings we can throw

[tmontgomery]

The OTF usually assumes the message header of the IR is in use. Which is not a bad assumption.... still might be wrong, but it is "reasonable" IMO.

In terms of types larger than int, yes. :)

My own opinion is that if you are generating codecs using interfaces, then makes sense that you would be restricting yourself a bit and thus assume some checking on types in use. If you want more freedom, then not using interfaces might be a better choice (more freedom)..... I know, seems weird (and maybe wrong) to couple the two things, but languages and the use of interface does mean some restriction anyway.

Or can just generate the interface per schema. But that seems to go against the idea of using the interface in the first place (i.e. the interface should be as generic as possible. i.e. across schemas makes sense to me).

[kdkavanagh]

Updated the PR #653 to:

1. Warn if using interfaces and type would be casted up
2. Error if using interfaces and type is > uint16