-
Notifications
You must be signed in to change notification settings - Fork 319
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
Add preencoded JSON support. #139
base: master
Are you sure you want to change the base?
Conversation
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR #139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
@dhull Sorry for taking so long to get back to you on this. While looking at your change this approach occurred to me: Theoretically it'd be faster as well since its avoiding the copies to the internal Jiffy buffers (though that likely wholly depends on the size of the pre-encoded data being inserted (though if its tiny then you likely shouldn't be using this approach because its bypassing a bunch of safety checks)). Theoretically adding the ability to have pre-encoded keys and arbitrary key/value pairs could be added but I'd have to think harder on it. Adding arbitrary elements to an array should already just work with |
Thanks! That (4613640) is an impressively minimal solution. I had already coded a
Yes, I discovered that after I wrote some special-purpose code to handle it. :) |
a132437
to
704547f
Compare
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
This change allows users to insert pre-encoded JSON `iodata()` anywhere there can be a valid `json_value()` (i.e., anywhere except object keys). This approach occurred to me looking at PR davisp#139 from @dhull. The technical difference being that this approach does not copy the given `iodata()` into the output and instead re-uses the same input term as part of the output `iodata()`.
Issue #128 requested support for preencoded raw JSON in jiffy:encode. Since this is something that would be useful for me too I wrote some code to implement it. Is this something that you are interested in supporting in mainline jiffy? If so, let me know and I will continue with adding documentation to get this pull request to a mergeable state. As it is, I have used the syntax suggested in #128, namely
{json, JSON}
is accepted anywhere ajson_value()
is.I'm also considering adding support for partially-encoded objects and lists (where more fields could later be added to the object or more elements to the list).