I would've probably chosen context.State or context.Type; but to be frank "Context" always seemed a bit too generic to me. Looking at its definition it seems like something to carry a bunch of random stuff. Sort of like a knapsack!
Naming is not easy. As usual Dijkstra has something interesting to say about this topic! https://www.cs.utexas.edu/users/EWD/ewd09xx/EWD958.PDF > On Dec 1, 2018, at 6:51 PM, Sameer Ajmani <sam...@golang.org> wrote: > > For what it's worth, we considered various ways to shorten context.Context > before releasing it as open source. The obvious choice would be context.C, > but I was concerned this would encourage people to name their context > variables c, which conflicts with the common short name for channel > variables. Since we typically use the short name ctx, we also considered the > type name context.Ctx, but this seemed too arbitrary. We went with > context.Context because it's clear and doesn't introduce any unnecessary > confusion. > S > On Sat, Dec 1, 2018 at 1:25 PM Robert Engels <reng...@ix.netcom.com> wrote: > I agree. You need to understand the expected usage patterns (and possibly > other external and internal constraints) before you can claim that any design > “needs change”. > > On Dec 1, 2018, at 12:18 PM, Bakul Shah <ba...@bitblocks.com> wrote: > >> Reducing stutter.Stutter is a good thing. But coming up with meaningful >> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite >> hard (but ultimately rewarding as it forces you to think more clearly). >> And languages and practices evolve as people gain more experience >> so early practices should not be seen as a model for newer code. >> >> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows >> where the fixed point lies for this type. In my case I used currency.Type for >> its main type, not currency.Currency. The "fixed point" may in fact depend >> on a specific currency. >> >> Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*! >> >>> On Dec 1, 2018, at 9:53 AM, Robert Engels <reng...@ix.netcom.com> wrote: >>> >>> That was my point. The earliest practitioners and language designers used >>> the construct extensively but now others claim it is not the way. I find it >>> hard to believe that in testing the original Go design the creators didn’t >>> think about this - which means they decided it was fine. So why the change? >>> >>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate <tcolg...@gmail.com> wrote: >>> >>>> In the cases of time and context, the stutters appear in a primary type >>>> that is important to the package, but rarely appears directly in normal >>>> API usage. >>>> E.g., time.Now(), context.Background(). >>>> Stutter is to be avoided. The package name can provide context. But >>>> stutter is preferred to, e.g. time.Type, where one package largely >>>> operates on one type >>>> I doubt there would be a peer reviewed paper on something which is >>>> basically just an opinion held by the language's earliest practitioners. >>>> It doesn't mean the idea does not have merit though. >>>> >>>> On Sat, 1 Dec 2018, 14:19 Robert Engels, <reng...@ix.netcom.com> wrote: >>>> In another thread, it has been brought up that things like time.Time are >>>> no good. But this format is pervasive. Even newer packages like >>>> context.Context. >>>> >>>> It seems to have been this way for a long time. >>>> >>>> It there some reasoned paper on why this is now so frowned upon? >>>> >>>> -- >>>> 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. >> > > -- > 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.
