-
Notifications
You must be signed in to change notification settings - Fork 360
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
Is there a plan to expose the internal decoder for buffer use case? #711
Comments
I didn't get it. Decoder only holds the string you pass, there is no buffer.. |
What I mean by using "buffer" is to refer to a new kind of Decoder that is different from the current exposed Decoder. In the current implementation, the Lines 139 to 143 in e2ff8ac
The StreamDecoder accepts an IO stream, and decodes data from it. Meanwhile, there could be a |
Why not directly use sonic/decoder/NewDecoder()? It can do everythin including set options |
Thanks! That's what I need. |
In the current implementation, each Unmarshal will create a new decoder:
sonic/sonic.go
Lines 113 to 124 in 4a3e8af
There is already a Reset method in the underlying decoder, however, only the streaming decoder can call it:
sonic/internal/decoder/api/stream.go
Line 90 in 4a3e8af
In our scene, we process fixed JSON string and want to cache the decoder instead of creating a new one each call. Wrapping the fixed JSON strings as an io stream is unavailable so we can't use StreamDecoder.
It would be helpful to provide a way to expose the internal decoder, for example, under the name "BufferDecoder" and so on. We would like to contribute if this is acceptable.
The text was updated successfully, but these errors were encountered: