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

Use font spec names for scalar types in codegen inputs #84

Closed
rsheeter opened this issue Oct 24, 2022 · 3 comments
Closed

Use font spec names for scalar types in codegen inputs #84

rsheeter opened this issue Oct 24, 2022 · 3 comments

Comments

@rsheeter
Copy link
Collaborator

Today, with the exception of Uint24, we use Rust type names for scalars. Use the names given in https://learn.microsoft.com/en-us/typography/opentype/spec/otff#data-types instead, e.g. uint16 instead of u16, etc.

@cmyr
Copy link
Member

cmyr commented Oct 31, 2022

thinking about this a bit more:

  • we need a distinction between 'raw' (bigendian) and native types.
  • we could say that the names in the spec are the 'raw' types, but this gets weird and unclear: we end up with uint16/u16, and then FWORD/FWord, and then Fixed/what, exactly? Basically this seems extremely confusing.
  • I believe we want to privilege the native types, since they will be used much more, and ultimately they're what matters; the raw types are essentially an encoding detail.
  • So this means we probably end up with raw types that something like BigEndian<u16>, Raw<u16> (same idea, different name) or RawU16 (a non-generic type, that follows a "prepend 'Raw' to indicate the raw type" naming convention).
  • And then a consequence of that is that the types in our codegen inputs, in the general case, no longer reflect an actual type in our code at all. As in: in our inputs we say uint16 and UFWORD, but in our code we have types like u16/BigEndian<u16> or UfWord/RawUfWord.

Does this bother us? it does not especially bother me in a world where these inputs really are some sort of language-agnostic schema, but if we are treating these inputs as a project-specific shorthand for what we're generating, then I don't love it.

@rsheeter
Copy link
Collaborator Author

rsheeter commented Nov 5, 2022

Does this bother us?

I would argue the codegen inputs are incrementally moving closer to being a language-agnostic schema, that that is desirable, and that this is a clear step in that direction

@cmyr
Copy link
Member

cmyr commented Mar 15, 2023

This was addressed in #81

@cmyr cmyr closed this as completed Mar 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants