Re: [go-nuts] Preemptive interfaces in Go

Responses inline... On Wednesday, August 10, 2022 at 1:17:21 AM UTC-7 Henry wrote: > Someone mentioned that data is data and there is no need to hide > implementation details. If we are to use that reasoning, there is no need > for Go to allow un-exported fields/types/functions. Why do we need

Re: [go-nuts] Preemptive interfaces in Go

ode meets certain standards and is *idiomatically Go.* It took me ~15 months and just under 60 CRs to get Go *readability* (compared to 4 months and 3 CRs for Python). On Tuesday, August 9, 2022 at 1:08:42 PM UTC-7 bse...@computer.org wrote: > On Tue, Aug 9, 2022 at 1:52 PM Tim Peoples wr

Re: [go-nuts] Preemptive interfaces in Go

peoples.com wrote: >> >>> I can't speak to the *auto-generated swagger client* case but I believe >>> gRPC is still doing things the right way -- in that the framework defines >>> an interface I (the framework API consumer) then implements. IOW: I don't &

Re: [go-nuts] Preemptive interfaces in Go

face defines the API contract). I suspect you and I are saything the same thing. t. On Monday, August 8, 2022 at 12:51:29 PM UTC-7 bse...@computer.org wrote: > On Mon, Aug 8, 2022 at 12:51 PM Tim Peoples wrote: > >> I don't necessarily consider the "multiple implement

Re: [go-nuts] Preemptive interfaces in Go

oducer -- for one and only one impl -- and then adding a bunch of extra (often autogenerated) code to deal with that. t. On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote: > On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples wrote: > >> >> For years I've r

[go-nuts] Preemptive interfaces in Go

For years I've read the old adage, "Accept interfaces, return structs" and have spent years working to instill this understanding among my colleagues. I gathered a great many skills while learning Go (and acquiring readability) back in the day -- and one of the strongest of those is the idea

Re: [go-nuts] Re: Ternary ... again

Regarding your issues with the following... > I've lost count of the times I've had to change: > > return FooBar{ > Field: blah, > } > > To: > > var foo FooBar > if someCond { > foo.Field = blah > } else { > foo.Field = bar > } > return foo > ...I hardly consider that to be idiomat

[go-nuts] Re: My trouble about GO interface

I think the confusion comes from how you're exposing each interface -- or rather, how you seem to imply their use. In your example, you provide packages pet and filepath each of which define a Walk interface *plus* one or more structs that implement that interface. But, neither package consumes

[go-nuts] Re: github repo names with "go-" prefix?

...and yet, a vast majority of the instances where I see a go package hosted as "github.com/user/go-foobar", they are not using gopkg.in. I'm w/ Dave on this one; except in very rare instances, this shouldn't be done (and even then, you should try find a way to avoid it). Also, in many ways, t

Re: [go-nuts] github repo names with "go-" prefix?

On Saturday, December 23, 2017 at 11:36:45 AM UTC-8, Jakob Borg wrote: > > On 23 Dec 2017, at 19:18, Tim Peoples > > wrote: > > > > I've noticed a somewhat common practice of people naming their github > repositories with a "go-" prefix (and the

[go-nuts] Re: github repo names with "go-" prefix?

On Saturday, December 23, 2017 at 11:06:35 AM UTC-8, Dave Cheney wrote: > > On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples wrote: > > I've noticed a somewhat common practice of people naming their github > repositories with a "go-" prefix (and

[go-nuts] Re: github repo names with "go-" prefix?

yet may often be interpreted as a recommendation. However, I'll assume the genesis is elsewhere. On Saturday, December 23, 2017 at 10:18:14 AM UTC-8, Tim Peoples wrote: > > > I've noticed a somewhat common practice of people naming their github > repositories with a "go-

[go-nuts] github repo names with "go-" prefix?

I've noticed a somewhat common practice of people naming their github repositories with a "go-" prefix (and then, of course, subsequently dropping the prefix in the actual package name) -- yet a similar naming scheme doesn't seem to be commonplace among many other languages. Is this recommende

[go-nuts] Re: Dangers of package renaming

You may want to consider using a type alias -- similar to how golang.org/x/net/context is being transitioned to the standard library's context package. Also, Russ Cox wrote an excellent article abou

[go-nuts] Re: Bug report github.com/golang/glog

You're absolutely right -- and, if you'll notice, there's a TODO on the traceLocation.String() method to "clean this up". Granted, all it needs is a: if !t.isSet() { return "" } On Friday, November 17, 2017 at 5:27:49 PM UTC-8, Bri