Re: [go-nuts] Re: How to know if interface{} data is nil w/o reflecting?
I was trying to show that the current behavior is confusing and that
fmt.Print() needing to resort to panic-and-recover is kinda code smell, but
I sorts-of convinced myself that the current behavior is right, or at least
consistent.
In my code, I got bit because I sometimes use v *Type to denote "I may or
may not have a value here" (where Type is a value-type).
This is probably a bad practice on my behalf, because I break the Liskov
substitution principle: there is a value of `*Type` that is not a valid
value of `Type`, and I let this value slip by.
In this case, `v Type` implements Stringer (i.e. valid callee for
`v.String()`, but `v *Type`, in the strictest sense, does not.
The only reason we can write:
func (Type) String() string {...}
v *Type = &Type{...}
_ = v.String()
and have it compile, is syntactic sugar: `v` gets implicitly de-referenced,
and there's an implicit assumption that it's not nil.
And there's a matching syntactic sugar for converting `Type` to a `*Type`.
So, In the code:
func (Type) String() string {...}
v *Type = nil
r interface{} = v
_, ok = r.(Stringer)
What I really want to ask is "Can I, at runtime, call r.String()?", whereas
the question Go answers is "Is any of `r`, `*r`, or `&r` defines
.String()?" - which matches the static semantics of `r.String()`.
So, while I should probably not use *Type as a replacement for
Optional, I think it might make sense to have some operator that can
determine, at run-time, if a call `r.String()` is valid (including a
nil-check).
-- Aviv
On Saturday, April 11, 2020 at 4:48:28 PM UTC+3 ren...@ix.netcom.com wrote:
> I agree with the OP. The usefulness of nil interfaces is pretty limited.
> Show me a useful case that cant easily be implemented with non-nil
> interfaces.
>
> I would argue that allowing nil interfaces causes more subtle latent bugs
> and makes it harder to reason about the correctness of code when reviewing
> it.
>
> It just feels wrong. I realize I’m probably in the minority here but the
> OP is not alone.
>
> On Apr 11, 2020, at 8:20 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> On Fri, Apr 10, 2020 at 7:17 PM wrote:
>
>> I realize I'm reviving an age-old discussion here and apologize for
>> bringing up the undead. I happend to run into this when my application
>> panicked when some interfaces where initialized with nil mock objects
>> instead of being left uninitialized as in production mode.
>>
>
> Let's imagine a world in which `foo == nil` also is true if `foo` is an
> interface-value containing a nil-pointer. Let's say in this world, someone
> sends a message to golang-nuts. They wrote a mock for the same code. And
> since it's just a mock, they just returned static value from its methods
> and didn't need to care if the pointer was nil or not. They are confused,
> because the passed in this mock, but the code just assumed the field was
> uninitialized and never called into their mock. What would you tell them?
> Why is their confusion less valid?
>
> This would be an example where a nil implementing fooer is never caught:
>>
>> type fooer interface {
>> foo()
>> }
>>
>> type other struct{}
>>
>> func (o *other) foo() {} // implement fooer
>>
>> func main() {
>> var f fooer
>>
>> var p *other // nil
>> f = p // it is a fooer so I can assign it
>>
>> if f == nil {
>> // will not get here
>> }
>> }
>>
>>
>> My confusion comes from the point that the nil interface is apparently
>> not "a nil-pointer with the correct method set" while *other is even if nil.
>>
>
> In the code you posted, even a nil *other is a perfectly fine
> implementation of fooer. You can call `(*other)(nil).foo()` without any
> problems.
> So, as you illustrated, calling methods on a nil-pointer can be totally
> fine. A nil-interface, OTOH, doesn't have any methods to call, as it
> doesn't contain a dynamic value. If you write `(*other)(nil).foo()`, it is
> completely clear what code gets called - even if that code *might* panic.
> If you write `fooer(nil).foo()`, what code should be called in your opinion?
>
> I think it's easy to see that a nil-interface and a nil-pointer stored in
> an interface are very different things. Even from first principles, without
> deep knowledge of the language. And if they are obviously different, I
> don't understand why you'd find it confusing that they are not the same in
> this particular manner.
>
> The above is a case where that might happen. In can be worked around but
>> it is unexpected unless the programmer is deeply rooted in the language
>> definition.
>>
>
> I fully agree with that. What I *don't* agree with, is where you attribute
> the problem here. You say, the problem is that the nil-check is
> ill-behaved. I say that - if anything - the original nil-assignment is
> ill-behaved. Having `(fooer)((*other)(nil)) == nil` be true is semantically
> wrong, because by checking against `nil`,
[go-nuts] Re: About Libraries Versioning
Summaries my conclusions on this journey: https://posener.github.io/branch-strategy/ Enjoy! On Wednesday, November 20, 2019 at 3:42:11 PM UTC+2, Eyal wrote: > > Hi > > The recommended way <https://blog.golang.org/v2-go-modules> to create a > new version for a go library is by copying the library code to a v2 > directory. I am against this approach from the following reasons: > >1. Code duplication: harder to back port fixes, harder to follow, not >"nice". >2. Commits history contains history of all versions, which is messy. >3. Project root is still the oldest version. >4. Feels like a workaround. > > There is another option - much more elegant, also mentioned in the cited > blog post - to use branches as versions. In this way there is no code > duplication, fix commits can be usually cherry-picked to older versions, > commit tree reflects only the current version history and the main view and > project root are the latest version. The down side of this approach, as > mentioned in the blog post, is that "tools that are not version-aware — > including the go command in GOPATH mode — may not distinguish between major > versions". > > My opinion is that the recommended solution is kind of a workaround. Is it > the solution for the long run? Will go modules start having "v*" sub > directories with code duplication? It feels like a wrong direction to the > community to me. > > I would appreciate if you have any solutions or opinions about it. > > Thanks! > Eyal > -- 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/634dee63-079a-47e9-af38-c53bc2787490%40googlegroups.com.
Re: [go-nuts] About Libraries Versioning
Of coarse, sorry for not mentioning it. I still think that this is a major issue. On Wednesday, November 20, 2019 at 3:47:25 PM UTC+2, Jan Mercl wrote: > > On Wed, Nov 20, 2019 at 2:42 PM Eyal > > wrote: > > > The recommended way to create a new version for a go library is by > copying the library code to a v2 directory. > > Only if the new version that breaks backward compatibility. Bug fixes > and/or new features do not need such switch. > -- 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/d0b49ee2-e666-4cdb-b862-024a99c8d236%40googlegroups.com.
[go-nuts] About Libraries Versioning
Hi The recommended way <https://blog.golang.org/v2-go-modules> to create a new version for a go library is by copying the library code to a v2 directory. I am against this approach from the following reasons: 1. Code duplication: harder to back port fixes, harder to follow, not "nice". 2. Commits history contains history of all versions, which is messy. 3. Project root is still the oldest version. 4. Feels like a workaround. There is another option - much more elegant, also mentioned in the cited blog post - to use branches as versions. In this way there is no code duplication, fix commits can be usually cherry-picked to older versions, commit tree reflects only the current version history and the main view and project root are the latest version. The down side of this approach, as mentioned in the blog post, is that "tools that are not version-aware — including the go command in GOPATH mode — may not distinguish between major versions". My opinion is that the recommended solution is kind of a workaround. Is it the solution for the long run? Will go modules start having "v*" sub directories with code duplication? It feels like a wrong direction to the community to me. I would appreciate if you have any solutions or opinions about it. Thanks! Eyal -- 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/c4b2f832-536c-469c-a1c3-2f2824e51d37%40googlegroups.com.
[go-nuts] gitfs - a complete solution for static files in Go code
Hi Gophers! Please take a look at gitfs <https://github.com/posener/gitfs>. Package gitfs is a complete solution for static files in Go code. When Go code uses non-Go files, they are not packaged into the binary. The common approach to the problem, as implemented by go-bindata <https://github.com/jteeuwen/go-bindata> is to convert all the required static files into Go code, which eventually compiled into the binary. This library takes a different approach, in which the static files are not required to be "binary-packed", and even no required to be in the same repository as the Go code. This package enables loading static content from a remote git repository, or packing it to the binary if desired or loaded from local path for development process. The transition from remote repository to binary packed content, to local content is completely smooth. The API is simple and minimalistic. The New method returns a (sub)tree of a Git repository, represented by the standard http.FileSystem interface. This object enables anything that is possible to do with a regular filesystem, such as opening a file or listing a directory. Additionally, the ./fsutil <https://github.com/posener/gitfs/blob/master/fsutil> package provides enhancements over the http.FileSystem object (They can work with any object that implements the interface) such as loading Go templates in the standard way, or walking over the filesystem. Cheers, Eyal -- 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/35d61468-51ac-409a-ad5c-6aaa6ede173d%40googlegroups.com.
[go-nuts] Chrome extension: enhances github with godoc.org synopsis and link
This chrome extension enhances Github Go projects: In file views: - It replaces the "last commit synopsis" with godoc.org synopsis. - It adds a link to the package documentation in godoc.org. Please feel free to download and use: https://chrome.google.com/webstore/detail/fhlenghekakdnaamlbkhhnnhdlpfpfej Github project: https://github.com/posener/chrome-github-godoc Cheers, Eyal -- 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/d50c85bc-98af-426c-8cd4-04facd50bd39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] fcontext: context with pseudo-constant values access-time
Hi, Please check out this implementation of idea that I had: It allows a constant access-time for the context values for the most common use-case. (The standard library access time is linear with the number of values in the context). I'd appreciate your feedback. https://github.com/posener/fcontext Cheers, Eyal -- 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/0c1aa113-d902-45f7-b1b5-59cf520bcdf2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] goreadme - automate Github Go projects readme files.
It would make sense that gddo will support versioned documentation. On Tue, Mar 12, 2019 at 4:41 AM Sameer Ajmani wrote: > Any of the above :-) > On Mon, Mar 11, 2019 at 1:13 PM Eyal wrote: > >> >> >> On Sunday, March 10, 2019 at 12:10:23 AM UTC+2, Sameer Ajmani wrote: >>> >>> Very nice. As a point of interest, I wrote something similar for Go >>> packages inside Google called "writeme". It worked with multiple languages >>> (the ones used inside Google), but had to be run manually. Your hook >>> integration is much nicer! >>> >>> Have you thought about how module information might be incorporated into >>> generated docs? We've been thinking about it; I'd be interested to hear >>> your thoughts. >>> >> Not sure what you mean, are you talking about things like "module name", >> "available module versions", per-version documentation? >> >>> S >>> >>> On Fri, Mar 8, 2019 at 8:34 AM Eyal wrote: >>> >>>> Hi >>>> >>>> I've created this Github App that automates the creation of readme >>>> files. >>>> It generates for Go project a readme up on the Go doc. >>>> >>>> I think it will be useful because it removes the burden of maintaining >>>> two documentation resources, and as a side effect, will result in improving >>>> the go doc of projects who use it. >>>> >>>> Please check it out: >>>> >>>> Website: https://goreadme.herokuapp.com. >>>> Github App page: https://github.com/apps/goreadme >>>> Github pages: >>>> >>>>- Server: https://github.com/posener/goreadme-server >>>>- Library: https://github.com/posener/goreadme >>>> >>>> Enjoy, >>>> Eyal >>>> >>>> -- >>>> 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...@googlegroups.com. >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] goreadme - automate Github Go projects readme files.
On Sunday, March 10, 2019 at 12:10:23 AM UTC+2, Sameer Ajmani wrote: > > Very nice. As a point of interest, I wrote something similar for Go > packages inside Google called "writeme". It worked with multiple languages > (the ones used inside Google), but had to be run manually. Your hook > integration is much nicer! > > Have you thought about how module information might be incorporated into > generated docs? We've been thinking about it; I'd be interested to hear > your thoughts. > Not sure what you mean, are you talking about things like "module name", "available module versions", per-version documentation? > S > > On Fri, Mar 8, 2019 at 8:34 AM Eyal > > wrote: > >> Hi >> >> I've created this Github App that automates the creation of readme files. >> It generates for Go project a readme up on the Go doc. >> >> I think it will be useful because it removes the burden of maintaining >> two documentation resources, and as a side effect, will result in improving >> the go doc of projects who use it. >> >> Please check it out: >> >> Website: https://goreadme.herokuapp.com. >> Github App page: https://github.com/apps/goreadme >> Github pages: >> >>- Server: https://github.com/posener/goreadme-server >>- Library: https://github.com/posener/goreadme >> >> Enjoy, >> Eyal >> >> -- >> 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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] goreadme - automate Github Go projects readme files.
Hi I've created this Github App that automates the creation of readme files. It generates for Go project a readme up on the Go doc. I think it will be useful because it removes the burden of maintaining two documentation resources, and as a side effect, will result in improving the go doc of projects who use it. Please check it out: Website: https://goreadme.herokuapp.com. Github App page: https://github.com/apps/goreadme Github pages: - Server: https://github.com/posener/goreadme-server - Library: https://github.com/posener/goreadme Enjoy, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: [Proposal] Goroutine Scoped Context
Part 2: scoped context proposal. https://posener.github.io/context-scoping/ Please post replies in the blog itself. Enjoy! On Wednesday, October 10, 2018 at 9:38:18 PM UTC+3, Eyal wrote: > > Hi, > I wrote a proposal about making the context goroutine scoped. > Please read the current design problems and how I suggest to solve them: > > https://posener.github.io/goroutine-scoped-context > > <https://posener.github.io/goroutine-scoped-context/> > Thanks, > Eyal > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] [Proposal] Goroutine Scoped Context
Hi, I wrote a proposal about making the context goroutine scoped. Please read the current design problems and how I suggest to solve them: https://posener.github.io/goroutine-scoped-context <https://posener.github.io/goroutine-scoped-context/> Thanks, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: HTTP/2 Adventure in the Go World
Hi Michal, Thanks, When removed, the netconn.TestConn tests are failing for race condition with the -race flag. On Monday, August 13, 2018 at 11:41:23 AM UTC+3, mic...@scylladb.com wrote: > > That's cool, I'm not sure if the locks on Conn object [1] are needed, > could it just rely on locking in http2? > > [1] https://github.com/posener/h2conn/blob/master/conn.go#L18 > > On Sunday, August 12, 2018 at 4:40:03 PM UTC+2, Eyal wrote: >> >> Hi, >> You are welcome to read a blog post I wrote about a short experience with >> HTTP/2 and Go. >> >> https://posener.github.io/http2/ >> >> Cheers, >> Eyal >> > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] HTTP/2 Adventure in the Go World
Hi, You are welcome to read a blog post I wrote about a short experience with HTTP/2 and Go. https://posener.github.io/http2/ Cheers, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] best practices of client middleware
In your tests in the round-trippers you do change the requests, as far as i can see. On Wed, Mar 7, 2018 at 10:13 AM Jakob Borg wrote: > On 7 Mar 2018, at 08:07, Eyal Posener wrote: > > > > Very Nice stuff - shame he didn't merge it. > > But I see that you changes the request in the RoundTrip function, which > is claimed as forbidden in the docs. > > Again, I don't understand why the docs forbid it… > > I expect that this is so that the user of the HTTP client API can > reasonably reuse a *http.Request. If the RoundTripper where allowed to > change it then it might have different URL, headers, method etc when the > request is completed and you’d have to recreate it again from scratch. > > //jb > > > -- sent from the milky way -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: best practices of client middleware
Very Nice stuff - shame he didn't merge it. But I see that you changes the request in the RoundTrip function, which is claimed as forbidden in the docs. Again, I don't understand why the docs forbid it... On Wednesday, March 7, 2018 at 1:52:55 AM UTC+2, Sangjin Lee wrote: > > I offered a PR on alice (which is a middleware library for the handlers) > that does that. It's essentially an application of the same pattern. We're > getting a lot of mileage for this. > > https://github.com/justinas/alice/pull/40 > > On Tuesday, March 6, 2018 at 6:41:53 AM UTC-8, Eyal Posener wrote: >> >> Good stuff, >> So I see that this library wraps the http.Client and doesn't use the >> roundtripper. >> Pretty elegant! >> >> I still have two questions about the standard library: >> >>- Didn't understand yet why it is not allowed to add headers in the >>roundtripper. >>- Is this a bit strange that the standard library provides a >>beautiful way to have server middleware, but no way to have client >>middlewares? >> >> Cheers, >> Eyal >> >> On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote: >>> >>> As far as I am aware, there is very little information about best >>> practices regarding client side middlewares. >>> >>> I though that having such support is neat idea and I have implemented >>> something (that I use for some time now, though still in beta) that you >>> might find useful for your use case. I have written small library that >>> describes client middleware protocol <https://github.com/delicb/cliware>, >>> some useful middlewares <https://github.com/delicb/cliware-middlewares> >>> and HTTP client <https://github.com/delicb/gwc> that's using these >>> libraries. >>> >>> This might solve your problem directly (writing new middleware is >>> trivial), but it might introduce dependency that you don't want, so I hope >>> this will provide inspiration on how you would do something similar >>> yourself. >>> >>> On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote: >>>> >>>> Hi >>>> >>>> I want to implement a client middleware - for example: sign the request >>>> body and add the signature as an HTTP header. >>>> I thought that the best way to do it is to implement a RoundTripper >>>> interface <https://golang.org/pkg/net/http/#RoundTripper> which up on >>>> request, calculate the signature, adds the header, and invoke a "next" >>>> ToundTripper. >>>> >>>> This could be a very generic implementation, which i can inject to any >>>> client that uses the standard library http.Client. >>>> >>>> However, I found the following in the doc: >>>> >>>> // RoundTrip should not modify the request, except for >>>> // consuming and closing the Request's Body. RoundTrip may >>>> // read fields of the request in a separate goroutine. Callers >>>> // should not mutate the request until the Response's Body has >>>> // been closed. >>>> >>>> >>>> Is there a standard way to do it? >>>> >>>> Thanks, >>>> Eyal >>>> >>> -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: best practices of client middleware
Good stuff, So I see that this library wraps the http.Client and doesn't use the roundtripper. Pretty elegant! I still have two questions about the standard library: - Didn't understand yet why it is not allowed to add headers in the roundtripper. - Is this a bit strange that the standard library provides a beautiful way to have server middleware, but no way to have client middlewares? Cheers, Eyal On Tuesday, March 6, 2018 at 2:57:57 AM UTC+2, Bojan Delić wrote: > > As far as I am aware, there is very little information about best > practices regarding client side middlewares. > > I though that having such support is neat idea and I have implemented > something (that I use for some time now, though still in beta) that you > might find useful for your use case. I have written small library that > describes client middleware protocol <https://github.com/delicb/cliware>, > some useful middlewares <https://github.com/delicb/cliware-middlewares> > and HTTP client <https://github.com/delicb/gwc> that's using these > libraries. > > This might solve your problem directly (writing new middleware is > trivial), but it might introduce dependency that you don't want, so I hope > this will provide inspiration on how you would do something similar > yourself. > > On Monday, March 5, 2018 at 3:03:14 PM UTC+1, Eyal Posener wrote: >> >> Hi >> >> I want to implement a client middleware - for example: sign the request >> body and add the signature as an HTTP header. >> I thought that the best way to do it is to implement a RoundTripper >> interface <https://golang.org/pkg/net/http/#RoundTripper> which up on >> request, calculate the signature, adds the header, and invoke a "next" >> ToundTripper. >> >> This could be a very generic implementation, which i can inject to any >> client that uses the standard library http.Client. >> >> However, I found the following in the doc: >> >> // RoundTrip should not modify the request, except for >> // consuming and closing the Request's Body. RoundTrip may >> // read fields of the request in a separate goroutine. Callers >> // should not mutate the request until the Response's Body has >> // been closed. >> >> >> Is there a standard way to do it? >> >> Thanks, >> Eyal >> > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] best practices of client middleware
Hi I want to implement a client middleware - for example: sign the request body and add the signature as an HTTP header. I thought that the best way to do it is to implement a RoundTripper interface <https://golang.org/pkg/net/http/#RoundTripper> which up on request, calculate the signature, adds the header, and invoke a "next" ToundTripper. This could be a very generic implementation, which i can inject to any client that uses the standard library http.Client. However, I found the following in the doc: // RoundTrip should not modify the request, except for // consuming and closing the Request's Body. RoundTrip may // read fields of the request in a separate goroutine. Callers // should not mutate the request until the Response's Body has // been closed. Is there a standard way to do it? Thanks, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: http client for go-server-timing
Thanks for the CR Matt, that's very kind of you.
About the factory, I thought that some of the options would be sometimes
easier to define in construction time, and copy the object doesn't add
complexity to my opinion.
About two sets of optoins, except of the "WithName" option, there is no
"timingOptions", but it is interesting that you brought it up:
I initially intended to do something more general than only http client,
for example, a timing client that could behave similar for http client and
for sql connection.
I meet two problems:
1. It would be hard to define an interface that will be common: one would
interact with http request/response and one with sql query and arguments.
2. The sql package does not provide any sort of "RoundTripper" interface,
that could be used to wrap the sql calls, I found an open issue in github
<https://github.com/golang/go/issues/14468> about something similar to my
problem.
On Monday, February 26, 2018 at 5:56:28 PM UTC+2, matthe...@gmail.com wrote:
>
> Hi Eyal, here’s a code review.
>
> Perhaps there’s a simpler name? Something like “timing.Timer” would look
> better than “clienttiming.Timer”.
>
> return fmt.Sprintf("%s %s", req.Method, req.URL.Path)
>
> could just be
>
> return req.Method + “ “ + req.URL.Path
>
> which removes the package fmt dependency.
>
> The godoc summary could be improved with a bullet list or by rewriting “It
> provides:\n\n…”.
>
> Some of the godoc identifier descriptions are missing the period.
>
> I’m not sure about the Timer factory for http.Client and
> http.RoundTripper. I can see that two sets of options need to be provided,
> but the package API could be reduced by doing something like:
>
> func NewClient(ctx context.Context, timingOpts []Option, httpOpts []Option
> ) *http.Client
>
> There is a tradeoff in readability though. Maybe using the options pattern
> is adding unnecessary complexity here?
>
> Thanks for the MIT licensing.
>
> Matt
>
> On Monday, February 26, 2018 at 4:16:04 AM UTC-6, Eyal Posener wrote:
>>
>> Hi,
>> Recently mitchellh wrote a really awesome library
>> <https://github.com/mitchellh/go-server-timing> that provide HTTP
>> middleware for server-timing headers.
>> I saw that and thought it would be really nice to automate those headers
>> for HTTP calls between servers.
>>
>> So I created this library: https://github.com/posener/client-timing.
>>
>>- An HTTP Client or RoundTripper, fully compatible with Go's standard
>>library.
>>- Automatically time HTTP requests sent from an HTTP handler.
>>- Collects all timing headers from upstream servers. So if you called
>>server A, A called B and B called C, you'll get all the information in
>> the
>>response, assuming all the servers used the middleware and the timing
>>client.
>>- Customize timing headers according to the request, response and
>>error of the HTTP round trip.
>>
>> Would love to hear your feedback about it.
>> Cheers,
>> Eyal
>>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] http client for go-server-timing
Hi, Recently mitchellh wrote a really awesome library <https://github.com/mitchellh/go-server-timing> that provide HTTP middleware for server-timing headers. I saw that and thought it would be really nice to automate those headers for HTTP calls between servers. So I created this library: https://github.com/posener/client-timing. - An HTTP Client or RoundTripper, fully compatible with Go's standard library. - Automatically time HTTP requests sent from an HTTP handler. - Collects all timing headers from upstream servers. So if you called server A, A called B and B called C, you'll get all the information in the response, assuming all the servers used the middleware and the timing client. - Customize timing headers according to the request, response and error of the HTTP round trip. Would love to hear your feedback about it. Cheers, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] "Try Go" in golang.org stopped working properly?
When I "Run", can't see the proper output, just "Program exited". Only after changing "Hello World" to another example and then back to "Hello World" I see the right output: Hello, 世界 Program exited. -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Be Careful with Table Driven Tests and t.Parallel()
Hi, A small talk about table driven tests and t.Parallel - it is dangerous! https://gist.github.com/posener/92a55c4cd441fc5e5e85f27bca008721 -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: [ANN] A Typed ORM Library
Nice stuff Alexey! thanks for this link, haven't seen it so far.
Seems like we both got frustrated from the same issues with existing
solutions :-)
We took pretty different approaches to solve the typed-ORM problem though.
The reform library has a larger run-time content, and keeps the generated
code minimal, which is a very nice idea!
However, as it seems to me, there are still a lot of interface{}s, and
strings to pass to the library functions, which I try to avoid. The current
proposed orm implementation leaves zero guessing - the user does not need
to know column names, SQL queries, expressions or types. All the functions
are fully typed, which leaves no room for run-time bugs. I intend to keep
it like that as much as possible.
I would love to hear your opinion about it, and if you could enlighten me
with obstacles I will find in future development of this library, since it
seem like you have some experience in this field.
Cheers!
On Saturday, December 23, 2017 at 9:21:09 PM UTC+2, Alexey Palazhchenko
wrote:
>
> Hi,
>
> There is also https://github.com/go-reform/reform.
>
> –-–
> Alexey «AlekSi» Palazhchenko
>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: [ANN] A Typed ORM Library
Hi Tamas, Thanks for the link, haven't seen that tool. Actually, as I understand, it is exactly the opposite, xo generates go code from SQL database. A comparable tool I found is https://github.com/relops/sqlc. On Friday, December 22, 2017 at 10:49:37 PM UTC+2, Tamás Gulácsi wrote: > > Have you seen knq/xo ? -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] [ANN] A Typed ORM Library
Hi
In the last month I spent my free time on creating a typed ORM library for
Go.
The motivation was that the currently most popular ORM library for Go: GORM
<http://jinzhu.me/gorm/>, lacks type safety, has poor performance and, to
my opinion, has unclear API.
Don't get me wrong, GORM is great, but I think that the go community can
have something more Go-ish.
So what was I thinking about?... About this: https://github.com/posener/orm
What is it? A command line that generates typed ORM code for a specific
struct.
The generated code does not use any interface{}, everything is typed! From
function arguments for insert operations, to arguments that are passed to a
where statement, and to returned values from a query operation. No more
guessing, no more run time failures.
The current implementations supports:
* Two database drivers: mysql (tested with mysql 5.6), and sqlite3
* Relatively simple API.
* Create table, simple migrations (add column, add foreign key column)
* Tables relations: one to one, one to many.
* Query: select columns, filter with where, group by, order by, joins (by
primary key(s)), rows count.
* Insert: a row. returned value is typed and has the primary key(s) filled.
* Delete: according to a where statement.
* Update: only to a specific value.
Simple benchmarks are available, showing performance similar to raw SQL
queries performance.
This is a big task, and to my opinion, it is an important one.
I would love to get help! and this project is on it's first stages,
everything is open!
* Add support for other databases.
* Add functionalities.
* Suggest ideas.
* Suggest better design.
* Suggest better API.
* Wider auto migration options.
* Support migration scripts generation.
* Improve documentation, add examples, improve wiki.
* Add tests.
Please visit https://github.com/posener/orm, star, and contribute.
And please, your opinion about it is appreciated!
Cheers,
Eyal
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Story: writing scripts in Go
Hi, I wrote a story about my experience in trying to write scripts in Go <https://gist.github.com/posener/73ffd326d88483df6b1cb66e8ed1e0bd>. Would love your opinion about it! Please comment in the gist itself, and not here. Cheers, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Function Failure Reporting: Error or OK bool
An article about the different Go conventions of function failure reporting https://gist.github.com/posener/a303becac35835ad7bf5e15fe061893e Enjoy! :-) -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: bash completion for flag package
No subcommand options :-)
On Wednesday, May 24, 2017 at 3:21:23 AM UTC+3, Will Faught wrote:
>
> Can it complete subcommands?
>
> By the way, there's a small syntax error in the readme example:
> []string{"work", "dring}
>
> On Tuesday, May 23, 2017 at 12:21:07 PM UTC-7, Eyal Posener wrote:
>>
>> I recently did the complete package <https://github.com/posener/complete>,
>> that enables bash completion for the go command line.
>> I came to be really satisfied with the result, but the package downside
>> is that the completion can be inconsistent with the actual flags provided
>> by the program.
>> I thought how is it possible to add support to the standard library flag
>> package for automatic bash completion, more or less in the same way.
>> (Including installation, and that the program binary will provide bash
>> completion for itself)
>>
>> Here is what I came out with: https://github.com/posener/flag.
>>
>> It is 100% interchangeable with the standard library flag package.
>> The implementation is also interesting, I only add to make
>> 'flat.Flag.Value' implement an interface I called 'Completer'. All the
>> standard library flags, which do not implement this interface don't
>> complete anything (which is fine) and additional flag types can complete
>> all sort of stuff.
>>
>> Please let me know your opinion about it.
>>
>> Cheers,
>> Eyal
>>
>
--
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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] bash completion for flag package
I recently did the complete package <https://github.com/posener/complete>, that enables bash completion for the go command line. I came to be really satisfied with the result, but the package downside is that the completion can be inconsistent with the actual flags provided by the program. I thought how is it possible to add support to the standard library flag package for automatic bash completion, more or less in the same way. (Including installation, and that the program binary will provide bash completion for itself) Here is what I came out with: https://github.com/posener/flag. It is 100% interchangeable with the standard library flag package. The implementation is also interesting, I only add to make 'flat.Flag.Value' implement an interface I called 'Completer'. All the standard library flags, which do not implement this interface don't complete anything (which is fine) and additional flag types can complete all sort of stuff. Please let me know your opinion about it. Cheers, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: New fully featured bash completion for go - written in go
The right installation commands are: go get github.com/posener/complete/gocomplete gocomplete -install You can also view the code in https://github.com/posener/complete On Saturday, May 13, 2017 at 11:29:47 AM UTC+3, Eyal Posener wrote: > > Simple to install (Assuming GOPATH and PATH are correct): > > go install github.com/posener/complete/gocomplete > gocomplete -install > > > Features: > >- Complete go command, sub commands and flags. >- Complete package names, .go files and ellipsis when necessary. >- Complete test names after -run flag! > > Works with bash / zsh shells > > This is also a package, that enables writing bash completion scripts, or > add them to an existing go program. > > Please, open issues, contribute and star! > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] New fully featured bash completion for go - written in go
Sure, open an issue, I'll fix that On Sunday, May 14, 2017 at 10:30:57 AM UTC+3, Frank Schröder wrote: > > It's not how other completions work, it's redundant and makes it harder to > read. > > Frank Schröder > > > On 14. May 2017, at 09:04, Eyal Posener > > wrote: > > > > currently all relative directories are completed with the `./` prefix, > Does it make any problems? > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] New fully featured bash completion for go - written in go
On Sunday, May 14, 2017 at 9:06:45 AM UTC+3, Frank Schröder wrote: > > I'll look into this. So far I've spent 30 min on this. :) which dir > pattern should I use for directory completions so that the suggestions > don't start with ./ ? > currently all relative directories are completed with the `./` prefix, Does it make any problems? > > Eg consul agent -server -data-dir ./data > > Frank Schröder > > On 14. May 2017, at 07:46, Eyal Posener > > wrote: > > Frank, sweet! > > Notice that you can build custom completions, such as completing agent > names in consul exec -node and service names after -service and > so on. > Also, you may suggest to add this code to the main consul repo. > > On Sunday, May 14, 2017 at 3:58:37 AM UTC+3, Frank Schröder wrote: >> >> This is awesome. I've immediately started working on >> https://github.com/magiconair/consulcomplete :) >> >> Frank >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/ZcbRJuJJrsI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] New fully featured bash completion for go - written in go
Frank, sweet! Notice that you can build custom completions, such as completing agent names in consul exec -node and service names after -service and so on. Also, you may suggest to add this code to the main consul repo. On Sunday, May 14, 2017 at 3:58:37 AM UTC+3, Frank Schröder wrote: > > This is awesome. I've immediately started working on > https://github.com/magiconair/consulcomplete :) > > Frank > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] New fully featured bash completion for go - written in go
Thanks! On Saturday, May 13, 2017 at 10:03:25 PM UTC+3, Jonathan Yu wrote: > > Nifty! Do the bash completion scripts need to be dynamically regenerated? > I guess so for some of the features like completing on package names. > Not sure I understand your question, but the bash completion script does not need to be regenerated. What happens under the hood is that there is a go binary that completes the next word. the go binary is called by the shell when the tab key is pressed. What that tells the shell to call that binary for completion is a line in the bashrc or zshrc, which does not need to be changed, and is added when you type `gocomplete -install`. > > It seems useful to have some Go completions (e.g. go in == go > install) available as part of distro packages. > > On Sat, May 13, 2017 at 1:29 AM, Eyal Posener > wrote: > >> Simple to install (Assuming GOPATH and PATH are correct): >> >> go install github.com/posener/complete/gocomplete >> gocomplete -install >> >> >> Features: >> >>- Complete go command, sub commands and flags. >>- Complete package names, .go files and ellipsis when necessary. >>- Complete test names after -run flag! >> >> Works with bash / zsh shells >> >> This is also a package, that enables writing bash completion scripts, or >> add them to an existing go program. >> >> Please, open issues, contribute and star! >> >> -- >> 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...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>, > Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>, > Facebook <https://facebook.com/jawnsy> > *“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* — > Samuel Beckett, Worstward Ho (1983) > > “In an adaptive environment, winning comes from adapting to change by > continuously experimenting and identifying new options more quickly and > economically than others. The classical strategist's mantra of sustainable > competitive advantage becomes one of serial temporary advantage.” — > Navigating > the Dozens of Different Strategy Options > <https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options> > (HBR) > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] New fully featured bash completion for go - written in go
Simple to install (Assuming GOPATH and PATH are correct): go install github.com/posener/complete/gocomplete gocomplete -install Features: - Complete go command, sub commands and flags. - Complete package names, .go files and ellipsis when necessary. - Complete test names after -run flag! Works with bash / zsh shells This is also a package, that enables writing bash completion scripts, or add them to an existing go program. Please, open issues, contribute and star! -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] uint type safety in go
Thanks for the answer. Very interesting. About the run time cost, does go always prefer safety over efficiency? or there is some kind of delicate balance between the two? On Tuesday, March 14, 2017 at 4:12:31 PM UTC+2, Ian Lance Taylor wrote: > > On Tue, Mar 14, 2017 at 6:48 AM, Eyal Posener > wrote: > > I was thinking about the type safety of uint in go, and comparing it for > a > > similar problem. > > > > If I have this go code: > > > > var x uint > > x-- > > > > The value of x is then the maximal value of uint, which is probably not > what > > the gother wanted (I think, is there any particular use cases for that > that > > you know of?) > > > > So my question is: why does go allow that, and for example panics on > index > > out of range of an array? Doesn't it make sense that it also should > panic in > > this case? > > Well, there are also uses for modulo arithmetic. If we make this > panic, writing the equivalent operation that doesn't panic seems > awkward. I think there is a better case to be made that signed types > should panic on overflow, the main question there being the run time > efficiency cost. > > In any case it's not a change we can make now. > > Ian > -- 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. For more options, visit https://groups.google.com/d/optout.
[go-nuts] uint type safety in go
I was thinking about the type safety of uint in go, and comparing it for a similar problem. If I have this go code: var x uint x-- The value of x is then the maximal value of uint, which is probably not what the gother wanted (I think, is there any particular use cases for that that you know of?) So my question is: why does go allow that, and for example panics on index out of range of an array? Doesn't it make sense that it also should panic in this case? Cheers, Eyal -- 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. For more options, visit https://groups.google.com/d/optout.
