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.
> >&g
>> 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: go
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:
Oh, thanks for pointing that out.
it is indeed very similar to my proposal. What do you think the chances of
getting it resurrected and merged? Is more discussion still needed with
respect to sync.Pool?
On Friday, August 9, 2019 at 6:15:31 PM UTC+2, Ian Davis wrote:
>
> You may also be interest
the modern world that seems rather rare (or
> very difficult to do well).
>
> -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
>
>
gt;> 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-nu
orld that seems rather rare (or very difficult to do well).-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 th
On Fri, 9 Aug 2019, at 3:33 PM, Jonathan Hall wrote:
> *I debated posting here, or straight to GitHub. If that's the better place, I
> can move the thread there. * I have long wanted proper streaming support in
> the `encoding/json` library. Lately I’ve been doing some digging to
> understand th
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, bur
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
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 > wrote:
> >
> > Can you say more? Better in which way?
>
> Better in the way that it wouldn't change existing code.
That doesn
On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall wrote:
>
> Can you say more? Better in which way?
Better in the way that it wouldn't change existing code. Also, I think
the use cases for existing and proposed json encoders/decoders are
different enough to justify a separate implementation. A wihle a
Can you say more? Better in which way?
On Friday, August 9, 2019 at 4:46:19 PM UTC+2, burak serdar wrote:
>
>
> Instead of modifying the existing Encoder/Decoder, wouldn't it be
> better to do this as a separate encoder/decoder?
>
>
>
>
> >
> >
> > --
> > You received this message because yo
On Fri, Aug 9, 2019 at 8:33 AM Jonathan Hall wrote:
>
> I debated posting here, or straight to GitHub. If that's the better place, I
> can move the thread there. I have long wanted proper streaming support in the
> `encoding/json` library. Lately I’ve been doing some digging to understand
> the
14 matches
Mail list logo
