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

Kubernetes JSON #7

Closed
inteon opened this issue Jun 18, 2022 · 5 comments
Closed

Kubernetes JSON #7

inteon opened this issue Jun 18, 2022 · 5 comments

Comments

@inteon
Copy link

inteon commented Jun 18, 2022

FYI: in https://github.com/kubernetes-sigs/json Kubernetes hosts their patched version of json v1.
Ideally, this implementation readily supports the features that were added in that repo.

@mvdan
Copy link
Collaborator

mvdan commented Jun 18, 2022

I skimmed their README file, and I'm fairly sure that all of those are possible on this API with minimal effort. For example, erroring on duplicate fields already happens by default, and erroring on unknown fields is supported via RejectUnknownMembers.

Case-sensitive matching is also used by default here. And syntactic errors have offsets: https://pkg.go.dev/github.com/go-json-experiment/json#SyntacticError

As for trying to decode JSON numbers into interface{} as int64, you could do that kind of customization via Unmarshalers: https://pkg.go.dev/github.com/go-json-experiment/json#example-UnmarshalOptions-RawNumber

@inteon
Copy link
Author

inteon commented Jun 18, 2022

Great, how about differentiating between strict and non-strict errors:
https://github.com/kubernetes-sigs/json/blob/52af2062547443fa3cf74f6953fc77dee6331fc2/json.go#L96

@mvdan
Copy link
Collaborator

mvdan commented Jun 18, 2022

They are different types in this API (syntactic vs semantic errors), so you can differentiate them pretty easily via Go type assertions.

@dsnet
Copy link
Collaborator

dsnet commented Jun 18, 2022

One thing we don't support are "non-fatal" errors. The implementation currently eagerly stops upon the first semantic error encountered.

We decided to do eager error handling now, and provide an API in the future to opt-in to lazy errors. The problem with lazy errors is that multiple errors can occur and right now there is no standard way in Go to represent a list of errors. Eager errors avoids this issue since there can only be zero or one errors.

There's been recent discussion about multi errors upstream, so hopefully something useful comes out of that: golang/go#53435

@mvdan
Copy link
Collaborator

mvdan commented Jul 1, 2022

It seems like there's nothing else to do or answer here, so I'm closing this for now.

@mvdan mvdan closed this as completed Jul 1, 2022
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

3 participants