For what it's worth, in all this time, context.Context still looks clumsy to me and I wish you'd picked context.Ctx :)
My certainty level here is high, the intensity level is low. It's like: I'm pretty sure I like the red backpack better than the black one. But the black one is fine :) Niko On Sunday, December 2, 2018 at 3:52:03 AM UTC+1, Sameer Ajmani 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 <ren...@ix.netcom.com > <javascript:>> 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 >> <javascript:>> 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 <ren...@ix.netcom.com >> <javascript:>> 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 <tcol...@gmail.com >> <javascript:>> 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, <ren...@ix.netcom.com >> <javascript:>> 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...@googlegroups.com <javascript:>. >>> 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...@googlegroups.com <javascript:>. >> 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...@googlegroups.com <javascript:>. >> 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.
