Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-Go types do not appear to be correct #14

Open
BatmanAoD opened this issue Sep 14, 2020 · 0 comments
Open

Non-Go types do not appear to be correct #14

BatmanAoD opened this issue Sep 14, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@BatmanAoD
Copy link
Contributor

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.
@xuri xuri added the enhancement New feature or request label Jan 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants