I can understand that and it seems reasonable but if I’m writing a new Ring “class” and it supports both a standard and a concurrent version, I’m probably not going to create two packages. I would create one package named ring and have NewRing and NewSyncRing. Which is what I and I think you are saying, each case is unique and having a “rule” is too restrictive.
Good software design is applying patterns reasonably not as a matter of rules IMO. > On Dec 1, 2018, at 11:57 AM, Ian Lance Taylor <i...@golang.org> wrote: > >> 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.
