[go-nuts] Re: Alternatives to wrapping errors

Yes, of course I'm quite familiar with Go 1.13's error capabilities. github.com/pkg/errors is still useful when one wants to attach stack traces to errors. But this leaves my question open: What are alternatives to wrapping errors? (Other than passing around errors with no semantic meaning, a

[go-nuts] Alternatives to wrapping errors

I was recently catching up on the latest state of the github.com/pkg/errors package (https://github.com/pkg/errors/issues/245), when I noticed that Dave Cheney said: > I no longer use this package, in fact I no longer wrap errors. I'm curious what approach Dave uses now, but unless/until he wri

[go-nuts] GopherJS 1.16 released!

After lagging behind Go for about 2 years (since version 1.12), GopherJS 1.16.0+go1.16.3 has been released with Go 1.16 support! GopherJS compiles Go code to pure JavaScript code (not WebAssembly). It’s main purpose is to

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

You're absolutely right. I just meant that the tokenizer interface wouldn't be completely replaced. There are still some corner cases where it will be necessary. On Friday, August 9, 2019 at 11:41:17 PM UTC+2, burak serdar wrote: > > On Fri, Aug 9, 2019 at 3:32 PM Jonath

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

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:

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

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

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

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 > >

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

he 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- >

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 > wrote: > > > > Can you say more? Better in which way? > > Better in the way that it wouldn

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

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

[go-nuts] RFC for opt-in streaming support in encoding/json package

*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 current state of things, and I think I’ve come to grips w

[go-nuts] Re: Dangers of package renaming

the library are using a vendoring tool with semver support, but this is an assumption I'm willing to live with. Any drawbacks I'm not seeing with this approach? -- Jonathan On Saturday, December 2, 2017 at 4:33:06 PM UTC+1, Jonathan Hall wrote: > > I maintain an open-source

[go-nuts] Dangers of package renaming

I maintain an open-source Go package with a few dozen followers. (github.com/flimzy/kivik) I'm planning to transfer/rename the package to a new organization (new package name to be: github.com/go-kivik/kivik). I understand that GitHub will maintain a redirect from the old location to the new

[go-nuts] Re: ...interface{} vs interface{} + reflection

Nice find wrt: mgo. That is a good analogy. And thanks for your input. That is a good observation that it could also save some internal conversion. -- Jonathan On Tuesday, May 2, 2017 at 8:12:39 PM UTC+2, Jonathan Hall wrote: > > I have a public API that takes `...interface{}` as an ar

[go-nuts] ...interface{} vs interface{} + reflection

I have a public API that takes `...interface{}` as an argument. (For reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs ) I'm considering changing this to instead take `interface{}` as an argument, then using reflection to: - Validate that the underlying type is an array - Co

[go-nuts] Re: Best practice for client API with both context-aware and non-context-aware methods

Thank you, everyone, for the feedback. You've validated my thoughts on the matter. I just removed all of the non-Context methods from my library, and am much happier with it already. Cheers. On Saturday, April 15, 2017 at 2:49:55 AM UTC+2, Jonathan Hall wrote: > > I'm wor

[go-nuts] Best practice for client API with both context-aware and non-context-aware methods

I'm working on a client client API, and am accepting a `context.Context` argument as the first argument to each function. However, for ease of use, I'm also providing non-context aware versions of each method. So my API looks roughly like: FooContext(ctx context.Context, args...) Foo(a

[go-nuts] Custom collation

I need to collate some IPA transcriptions, which means that following the standard collation rules for a given language doesn't really make sense. As such, I wish to define my own collation order. Is there any documentation, howto, or other easier-to-digest documentation on this than what can