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

[write] Use Vec instead of BTreeSet for name records #1256

Merged
merged 1 commit into from
Nov 20, 2024
Merged

Conversation

cmyr
Copy link
Member

@cmyr cmyr commented Nov 20, 2024

It is an invariant that entries in the name_records array are sorted, and to enforce this at the type level the initial design used a BTreeSet for these records.

This didn't fully help, though, because it was still possible to have a duplicate entry in the array (the same
platform/encoding/language/nameId, mapped to different strings) since the string itself is included in the Eq method of NameRecord.

This patch tries to be less cute: it is now the responsibility of the caller to make sure that their data is right, and we will verify this at validation time.

Ultimately this probably deserves a builder (there's one in fea-rs that should maybe get moved over here?)

cc @simoncozens; I recall you not enjoying the ergonomics of the BTreeSet approach, so here you go 💁

It is an invariant that entries in the name_records array are sorted,
and to enforce this at the type level the initial design used a BTreeSet
for these records.

This didn't fully help, though, because it was still possible to have a
duplicate entry in the array (the same
platform/encoding/language/nameId, mapped to different strings) since
the string itself is included in the Eq method of `NameRecord`.

This patch tries to be less cute: it is now the responsibility of the
caller to make sure that their data is right, and we will verify this at
validation time.

Ultimately this probably deserves a builder (there's one in fea-rs that
should maybe get moved over here?)
@rsheeter
Copy link
Collaborator

since the string itself is included in the Eq method of NameRecord

I appreciate this being a problem but ... wouldn't using a map model this better? - (plat/enc/lang/nameid) => value

@cmyr
Copy link
Member Author

cmyr commented Nov 20, 2024

This is in generated code in write-fonts, where the types we're using are very close to what is in the spec. If we want to do something with a map, that would go in a NameBuilder or similar.

@cmyr cmyr merged commit bcd8ee0 into main Nov 20, 2024
10 checks passed
@cmyr cmyr deleted the name-record-vec branch November 20, 2024 19:43
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

Successfully merging this pull request may close these issues.

2 participants