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

YAML | JSON.mapping presence: true option. #4843

merged 1 commit into from Aug 18, 2017


Copy link

@akzhan akzhan commented Aug 17, 2017

Allows to distinguish absence of key-value pairs vs null/default values.

Fixes #4840.

Proposed by @asterite, I just added the specs.

Allows to distinguish absence of key-value pairs vs null values.
@akzhan akzhan force-pushed the json-yaml-key-presence-option branch from bcdf497 to 1a35ccc Compare August 17, 2017 19:09
Copy link

@ysbaddaden @RX14 I understand your concern that this bloats JSON.mapping and YAML.mapping a bit, but this bloat is very tiny in code and it's an optional feature (if you don't use it you don't need to learn it, and if you need it, it's there).

The nice thing about this is that you retain type safety and you keep the information of which keys were present in the original JSON. You can of course use JSON::PullParser or JSON.parse, but that is more tedious and less type-safe.

As a comparison, see this answer for how to do it in Go: you basically have to map the field to the raw bytes that came in the JSON, and then you have to parse it again... so you lose type-safety, and it's more tedious. I think it's nice if there's a built-in way to do it in the standard library.

As for a real use case: imagine an HTTP endpoint that accepts updates to an object. The client can specify which fields to update, and to clear a field sends {"field": null}. You have to know whether the field came to reset it. Right now there's no easy/elegant way to do it.

(but of course, like every PR since a few weeks ago, this has to be accepted by a few members, so my opinion alone doesn't count anymore: and that's very good)

Copy link

IMHO this is too much, but I don't use X.mapping myself, and since there are valid use cases, then it's acceptable.

Copy link

RX14 commented Aug 18, 2017

I can see the usecase much more clearly now, so yes it's a 👍 from me. Would be nice if there was a cleaner way to do this but there probably isn't unless we implement custom attributes and I have my own reservations about slinging around too much metadata.

Copy link

Sija commented Aug 18, 2017

Is there really a need for another option if it's only usable with nilable: true? Wouldn't be sufficient to include <field>_present? accessor when nilable option is set?

Copy link
Contributor Author

akzhan commented Aug 18, 2017

Yes, we need another option just because we have default option (that allowed without nilable too).

And presence option also has bool field overhead (sometimes unacceptable).

@RX14 RX14 merged commit 43c52d3 into crystal-lang:master Aug 18, 2017
@RX14 RX14 added this to the Next milestone Aug 18, 2017
@akzhan akzhan deleted the json-yaml-key-presence-option branch August 18, 2017 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

None yet

5 participants