undefined | Better HN

0 pointseuroderf2y ago0 comments

"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.

0 comments

huh? there's no dogma involved here, it's just an observation of the properties of the type

a context is created with each request, and destroyed at the end of it

and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

euroderfOP2y ago

In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it.

Are pitfalls ever actually encountered ?

preseinger2y ago

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error

if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

1 more reply

j / k navigate · click thread line to collapse

0 comments

preseinger2y ago

huh? there's no dogma involved here, it's just an observation of the properties of the type

a context is created with each request, and destroyed at the end of it

and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

euroderfOP2y ago

Are pitfalls ever actually encountered ?

preseinger2y ago

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error

if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

1 more reply

j / k navigate · click thread line to collapse