You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the map from XSD types to language-specific types in utils.go, it seems there are a number of problems with the non-Go languages:
char is used frequently in C and Rust, for instance with ID. These are mapped to strings in Go, TypeScript, and Java, but char is not long enough to store most data (it is a byte in C and a UTF-32 code point in Rust).
Similarly, a collection of strings in other languages are represented with a collection of char in C and Rust, rather than a collection of string-like data.
It appears that any is used to store raw bytes in TypeScript. Allocating a separate dynamically-typed value for every byte is wasteful and makes deserialized values difficult to use. I think Uint8Array would be preferable to Array<any> for these types.
Standard date/time types are only used in Go, but all five languages have standard-library types for dealing with dates and times.
The text was updated successfully, but these errors were encountered:
Looking at the map from XSD types to language-specific types in
utils.go
, it seems there are a number of problems with the non-Go languages:char
is used frequently in C and Rust, for instance withID
. These are mapped to strings in Go, TypeScript, and Java, butchar
is not long enough to store most data (it is a byte in C and a UTF-32 code point in Rust).char
in C and Rust, rather than a collection of string-like data.any
is used to store raw bytes in TypeScript. Allocating a separate dynamically-typed value for every byte is wasteful and makes deserialized values difficult to use. I thinkUint8Array
would be preferable toArray<any>
for these types.The text was updated successfully, but these errors were encountered: