You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We still need to interpret the Go style guide. There seem to be two possible views on this:
Gin's Context is acceptable: Since it implements the context.Context interface, it can be considered valid, and thus doesn't violate the style guide. Similarly, we could create other types like this:
typeinterfaceCustomContext {
context.Context// ...additional APIs that we need
}
Strict compliance: To adhere to the Go style guide strictly, we should always pass context.Context directly in function signatures. In this case, the design would need to change to separate the Context from custom APIs. For example, the function signature could be:
@xr I think it would be better to keep this issue in open state as an improvement reminder for the next major version of the gin
it's extremely disorienting that I must not use the gin.Context and need to use (*gin.Context).Request.Context() instead
PS:
I faced the similar situation with otel like @pepea23 in #3993, and when I found that my otel.Span just disappeared from the context I was very surprised
PPS:
Another funny thing that there is no one sample in the gin's documentation with the context usage in a case when we should pass it deeper to other components. I think it should the very first line in the README, for real
Hey guys,
We're having some discussions regarding whether or not Gin
Context
violates the Go context style guide. I'd like to hear your thoughts on this.According to the Go style guide (reference: Go Style Guide on Custom Contexts), it clearly states:
However, in the case of Gin's
HandlerFunc
, it passes a custom*Context
type.Even though the Gin
Context
implements all the methods of thecontext.Context
interface,as shown here
We still need to interpret the Go style guide. There seem to be two possible views on this:
Gin's
Context
is acceptable: Since it implements thecontext.Context
interface, it can be considered valid, and thus doesn't violate the style guide. Similarly, we could create other types like this:Strict compliance: To adhere to the Go style guide strictly, we should always pass
context.Context
directly in function signatures. In this case, the design would need to change to separate theContext
from custom APIs. For example, the function signature could be:What do you guys think?
The text was updated successfully, but these errors were encountered: