Input vs. output types

[Benjamin-Dobell]

This was just briefly touched on in #2, with relation to tts__SnapPoint vs tts__SnapPointParameters.

However, TTS regularly has two sets of corresponding types for input and output within TTS' APIs. Take for example the object state type (ObjectState.def.lua). They're defined with optional fields and "plain old data" shapes, and represent the data you can feed into TTS spawnObjectJSON method (once serialised).

However, when you call getJSON() or getData() TTS will return a more concrete type, where every field is guaranteed to exist, having been populated with their default values. TTS also (typically) returns concrete Vector and Color types.

If we were to only have one, the input types are preferable, as the output types are compatible with the input types but not vice versa. However, I think long term we're going to have to bite the bullet and produce two sets of types (where appropriate). Chances are this will be a big breaking change.

Open to suggestions.

[Benjamin-Dobell]

ge_tts also runs into a similar problem and defines helper types using generics to keep things DRY. However, despite being shorter, I think the use of generics at scale just to avoid repeating one-self may complicate the types too much for casual observers. Just food for thought:

https://github.com/Benjamin-Dobell/ge_tts/blob/7ca6a01/Vector3.ttslua#L8-L16
https://github.com/Benjamin-Dobell/ge_tts/blob/7ca6a01/Vector3.ttslua#L43