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

Lenient numeric decoding #1606

Merged
merged 4 commits into from
Oct 9, 2024
Merged

Lenient numeric decoding #1606

merged 4 commits into from
Oct 9, 2024

Conversation

Baccata
Copy link
Contributor

@Baccata Baccata commented Oct 4, 2024

This adds opt-in logic to allow decoding numeric values from JSON strings.
This also exposes a new method on the SimpleRestJsonBuilder to configure the underlying JSON codecs, without having to duplicate the smart-builder methods every time we add new options.

PR Checklist (not all items are relevant to all PRs)

  • Added unit-tests (for runtime code)
  • Added documentation
  • Updated changelog

Comment on lines +81 to +85
/**
* Enables lenient decoding of numeric values, where numbers may be carried by JSON strings
* as well as JSON numbers.
*/
def withLenientNumericDecoding: JsoniterCodecCompiler
Copy link
Member

Choose a reason for hiding this comment

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

question: shall we just call it lenient decoding, in case we add more cases of leniency? such as, case-insensitivity (which might not be doable if there are members with names like foo and FOO, but might be possible in many cases)

Copy link
Member

Choose a reason for hiding this comment

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

and we'd just mention number handling because it happens to be the only thing for now

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'd rather have more granular options than a "one size fits all" option.

@Baccata Baccata marked this pull request as ready for review October 7, 2024 10:02
Copy link
Contributor

@lewisjkl lewisjkl left a comment

Choose a reason for hiding this comment

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

Just the one potential thing in the comment below, otherwise looks good 👍


def decodeValue(cursor: Cursor, in: JsonReader): Int = in.readInt()
final def decodeValue(cursor: Cursor, in: JsonReader): A =
if (allowJsonStringNumerics) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It's just one if statement, but I think this could be moved off the hot path?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question. In this case, it's hard : the problem is that due to the imperative nature of jsoniter, the logic is not compositional. If we want to get checks on the hotpath at all cost, that in an ideal world we'd have one class per combination of flags

  1. disallowed strings but allowed infinity
  2. allowed strings and allowed infinity
  3. disallowed strings and disallowed infinity
  4. allowed strings but disallowed infinity

Right now I'm accepting this boolean check as a compromise to avoid having to repeat inherently error-prone bits of logic in 4 different implementations. I'm not too happy about it but I'd rather live with it.

Copy link
Contributor

@lewisjkl lewisjkl Oct 9, 2024

Choose a reason for hiding this comment

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

I think I'm following, for some reason I thought that you could also do at the class level something like:

private val decodeV: (Cursor, JsonReader) => A = if (allowJsonStringNumerics) {
  (cursor, in) => // ...
} else {
  (cursor, in) => // ...
}

final def decodeValue(cursor: Cursor, in: JsonReader): A = this.decodeV(cursor, in)

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 mean, maybe you're seeing something I'm not seeing. I'd be delighted if you attempted and managed to avoid the boolean check on the critical path without inducing a lot of repetition in the code 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

also there's the question of : is a method dispatch faster than a boolean check in this context ? not sure

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah good point, it probably isn't worth worrying about, was mostly just asking to clarify my understanding

@Baccata Baccata merged commit ae5b9de into series/0.18 Oct 9, 2024
10 checks passed
@Baccata Baccata deleted the lenient-numeric-decoding branch October 10, 2024 10:32
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