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.
