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.
