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.
