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

✨ Improve JSON number parsing result #1158

Merged
merged 7 commits into from
May 19, 2024

Conversation

NeunEinser
Copy link
Contributor

This examines the number at parse time to determine whether it is an integer or a float. This allows for better checking later on, when someone tries to define decimal places for a number that is defined as an integer.

Additionally, I simplified some of the other JSON parser definitions to use core.setType instead of doing that manually.

This improves json number parsing to distinguish between integers
and floats.

This allows checkers in the future to mark places were an integer
is expected but a float is defined as incorrect.

Also using bigint makes sure numbers are exact, which could in
theory be relevant for range checks
readonly type: 'json:number'
readonly value: number
readonly children: [core.LongNode | core.FloatNode]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be a LongNode? Wouldn't IntegerNode be enough, because this is JSON?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used long node because it uses a bigint internally, so the parsed value can be more precise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I mean. Does it need that precision? Aren't JSON values inherently restricted by the precision of JS numbers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just figured there isn't any disadvantage of using a bigint. Not sure what the json spec says, and also not sure how Mojang handles this when codec specifies a long.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair. I think bigints are a bit annoying in JS, for example if you have int @ 1..2 and you parse the 1..2 range as numbers but the json number itself is a bigint, you need to convert one to the other to compare them. Either way no major issues so I'm fine with it.

packages/json/test/parser/number.spec.ts Outdated Show resolved Hide resolved
@misode misode merged commit d984835 into SpyglassMC:main May 19, 2024
3 checks passed
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.

3 participants