As an aside, I find that many programmers have a strong desire to aptly taxonomies to their work, they want to find _differences_ between two things so they can be separated and classified. I think to write successful Go, you should look for similarities and combine things with a similar purpose into a package. For example, net/http contains both http client and server facilities, because they both relate to the use of http. The prevailing style in other languages would have these placed in separate packages, one for client, one for server, and a third for things which are common to both. I think this is unnecessary.
On Thursday, 15 December 2016 07:09:35 UTC+11, Dave Cheney wrote: > > It's pretty consistent with the message I've been pushing for a while; > each package should have a well defined purpose, and that purpose should be > enumerated by the pacakge's name. I find that when I apply that logic to my > own projects, I tend to have less packages, not more. > > On Thursday, 15 December 2016 03:23:17 UTC+11, adon...@google.com wrote: >> >> On Tuesday, 13 December 2016 20:06:49 UTC-5, Dave Cheney wrote: >>> >>> I advice caution, Go is not Java and does not permit circular >>> dependencies. The more packages you have, the greater the chance you have >>> of creating a circular dependency. >>> >> >> That's a rather dark viewpoint. Absent further information, there's >> nothing wrong with breaking up a large package into smaller ones, nor with >> using tools to help do so. Even packages with circular dependencies can be >> separated by using function or interface parameters to express the >> interdependence. Of course it can be overused, but so can any technique. >> > -- 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.
