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 > <mailto: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 >> <mailto: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 >> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
