On 14 December 2016 at 15:13, Dave Cheney <d...@cheney.net> wrote: > 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. >
There's a case to be made here for the combined power of internal packages and aliases (as proposed for Go 1.8). From the user's perspective, a single net/http package makes sense, but for the maintainers, breaking it up may lighten their burden. Within Google, the Go implementation of our in-house RPC system is a complex beast that would benefit from a little modularity, but we can't break the package up without changing its API. With aliases, it would be possible to define separate internal packages for common declarations, for clients, and for servers, and then define a "facade" package that exposes just the API. I realize you are no fan of the aliases proposal, but I think it provides real opportunities to solve problems of "programming in the large" that aren't just about temporary refactoring. -- 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.
