[go-nuts] Re: Handling nil embedded interfaces

1:32:42 AM UTC-8, Traun Leyden wrote: > > > What's the best practice around handling embedded interfaces that are nil? > > For example: > > https://play.golang.org/p/EcqV7h9cNU > > Is there a better way than wrapping the embedded interface's methods and > forwarding d

[go-nuts] Handling nil embedded interfaces

What's the best practice around handling embedded interfaces that are nil? For example: https://play.golang.org/p/EcqV7h9cNU Is there a better way than wrapping the embedded interface's methods and forwarding down as long as it's not nil? I guess another approach would be to create a

[go-nuts] json.Unmarshal and numbers: go 1.7 vs go 1.8

On go 1.7, I'm seeing a difference in behavior between json.Unmarshal and json.Decoder when it comes to json numbers. This test program which compares json.Unmarshal() vs. json.NewDecoder() behavior w.r.t to numbers works fine on go 1.8, but if I run it

Re: [go-nuts] json.Unmarshal and numbers: go 1.7 vs go 1.8

Ok thanks! Btw looks like the copy/paste turned 2^64 -> 264 On Saturday, July 15, 2017 at 11:34:18 AM UTC-7, Ian Lance Taylor wrote: > > On Sat, Jul 15, 2017 at 11:20 AM, Traun Leyden <traun@gmail.com > > wrote: > > > > On go 1.7, I'm seeing a

[go-nuts] Do tests run with "..." package expansion run with additional parallelism?

If tests are run via: go test -v github.com/org/repo/... will there be any additional parallelism compared to running: go test -v github.com/org/repo/package1 go test -v github.com/org/repo/package2 ? I'm asking because I'm seeing cases in the log output where the timestamp on later

[go-nuts] Re: Do tests run with "..." package expansion run with additional parallelism?

llel 1" to the args, but it didn't make any difference. Is there any way to serialize the execution of tests when using "..." to expand packages? On Monday, October 16, 2017 at 3:21:49 PM UTC-7, Traun Leyden wrote: > > > If tests are run via: > > go test -v github.com/

[go-nuts] Re: Do tests run with "..." package expansion run with additional parallelism?

That fixed it! I completely missed it because I was looking at the flag docs from "go test --help". But I see that flag is documented in "go build --help" On Monday, October 16, 2017 at 3:46:23 PM UTC-7, Dave Cheney wrote: > > The go tests packages in parallel (as distinct from running the

[go-nuts] Re: Aborting tests early if any fail + getting streaming output

Answering my own post: On Friday, September 29, 2017 at 1:35:24 PM UTC-7, Traun Leyden wrote: > > > Is it possible to abort running a test suite if one of the tests fails? > In my case I'm running the test against multiple packages: > > go test github.com/path/... > >

[go-nuts] Aborting tests early if any fail + getting streaming output

Is it possible to abort running a test suite if one of the tests fails? In my case I'm running the test against multiple packages: go test github.com/path/... and if one test fails, it seems to continue on running the rest of the tests. (if this is not the expected behavior, I can provide

[go-nuts] Flagging lazy-loaded fields as being unsafe to access directly

I'm trying to figure out a way to best signal to other developers maintaining a single package that a field is unsafe to access directly. In this case, it's being lazily loaded, and the only way to ensure it will be properly loaded is to access the method wrapper rather than directly

[go-nuts] Re: Flagging lazy-loaded fields as being unsafe to access directly

> type Foo struct { > bar string > } > > // Method wrapper that does lazy-loading > func (f *Foo) GetBar() string { > if f.bar == "" { > // lazy-load this from a database or some other expensive call > f.bar = "bar" > } > return f.bar > }

[go-nuts] Modifying AST and preserving comments

I'm trying to modify a source file and replace some function parameters based on their names. I was able to get some basics working by following this tutorial , however when I write the new file, it's deleting the existing comments. It looks like just