On Fri, Aug 9, 2019 at 2:10 PM Robert Engels <reng...@ix.netcom.com> wrote: > > I'm sorry, maybe I didn't understand your original concern. There is an > example of doing stream based processing in the json package (using Decoder). > > How is this not sufficient? > > The only problem I see with it is that it doesn't allow error > correction/continuation, but in the modern world that seems rather rare (or > very difficult to do well).
I was thinking similarly and after reading those github issues, it looks like the main problem is with Encoder, and not with Decoder. Encoder's problem can be solved by providing an unbuffered output option that directly writes to the io.Writer. I like the idea of stream-friendly marshaler/unmarshaler interfaces. > > -----Original Message----- > From: Jonathan Hall > Sent: Aug 9, 2019 11:00 AM > To: golang-nuts > Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json > package > > An interesting observation. > > Although in a sense, we already have the decoding half of that low-level > streaming API exposed by way of the `json.Decoder` type. > > Would you be suggesting that a separate, stream-based API makes sense even > within the stdlib? > > I'm not really sure what that separate API would look like, or do differently > than my proposal (I'm open to new ideas, though). > > Given that the "Go way" of handling streams is with io.Reader/io.Writer (as > opposed to events, for example), and the internal implementation of > `json/encoding` is already so close to that, I wonder if the APIs would end > up looking very much the same, anyway. > > Jonathan > > > On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote: >> >> In other environments (e.g. Java), the streaming processors are distinct >> from the instance oriented - usually for good reason as the APIs are very >> different - the former is usually event based, and the latter returns >> realized instances as a whole or an error. The streaming processors can >> often skip ill-formed entities, and/or have them manipulated during decoding. >> >> -----Original Message----- >> From: Jonathan Hall >> Sent: Aug 9, 2019 10:38 AM >> To: golang-nuts >> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json >> package >> >> Thanks for the reply. My responses inline below. >> >> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote: >>> >>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall <fli...@flimzy.com> wrote: >>> > >>> > Can you say more? Better in which way? >>> >>> Better in the way that it wouldn't change existing code. >> >> >> That doesn't seem like a benefit, in its own right >> >> I understand the desire not to just change code for its own sake, or add >> extra features nobody needs. But people have been asking for these types of >> features for several years. This doesn't seem like a frivolous code change >> to me. >> >>> >>> Also, I think >>> the use cases for existing and proposed json encoders/decoders are >>> different enough to justify a separate implementation. >> >> >> I don't think I agree with this. >> >> The proposal deals with a subset of current use cases, but not, strictly >> speaking, a _different set_ of use cases. And the number of commentators on >> the issues linked above, I think lends weight to the idea that the use cases >> this proposal addresses are not insignificant, or fundamentally "different". >> >> If I were to fork the standard `encoding/json` library, and add my proposed >> functionality, the code would still be 95% the same. Standard reasons for >> sharing code apply, as far as I can tell. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golan...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com. >> >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/718e2b9e-39e2-44f2-9308-8c94e31afbff%40googlegroups.com. > > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/924142684.7377.1565381399326%40wamui-agami.atl.sa.earthlink.net. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMV2RqpNx5G2OFmjEOC6gge5AaEQT737%2Bpq_ntALJ%2BWmNOebUw%40mail.gmail.com.
