I think context.Context is fine, it’s weird though I’ll admit. The way to fix it though it just to use dot imports, and encourage it! The only time dot imports don’t work is when there isn’t package stutter. Seems like a no brainer and you get the best of both worlds.
You have similar problems in the general case... say you are writing an image processing app, you are probably going to use stdlib image package and probably an image package in third party libraries - so you need to use import overrides anyway... Promote the use of dot for common “defined within the particular application scope” libraries. Most apps would probably dot import context because it is so pervasive. The method signatures would be far more readable when using common outside types as parameters, Time and Duration come to mind. People say, it makes things less clear, and I counter that variable inference is far worse and it’s done for the sake of less verbosity, and people love it... Since Map is a common interface, using collections.Map is just silly. And if you had a conflicting type then you fully qualify it. Seems pretty simple. > On Dec 1, 2018, at 8:51 PM, Sameer Ajmani <sam...@golang.org> 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 <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.
