On Sat, 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?
I don't think there is any hard and fast rule here. Each choice needs to be made in the appropriate context. We use testing.T, not testing.Testing. We use time.Time, not time.T. The goal should always be clarity for the reader. Effective Go, which was written very early on in the development of the language, has this to say: "The importer of a package will use the name to refer to its contents, so exported names in the package can use that fact to avoid stutter. (Don't use the import . notation, which can simplify tests that must run outside the package they are testing, but should otherwise be avoided.) For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader. Similarly, the function to make new instances of ring.Ring—which is the definition of a constructor in Go—would normally be called NewRing, but since Ring is the only type exported by the package, and since the package is called ring, it's called just New, which clients of the package see as ring.New. Use the package structure to help you choose good names." Ian > 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.
