> On Dec 14, 2016, at 12:50 PM, 'Alan Donovan' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > On 14 December 2016 at 15:13, Dave Cheney <d...@cheney.net > <mailto: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.
(Unlike Dave Cheney) I like this. I think a key distinction is that packages are *design* objects, not runtime objects — it is how you structure a piece of sottware, separate from its runtime behavior. A hierarchical design is a good thing but we don’t usually need to model hierarchies at runtime. In any case, a user of a package need not care how it is composed. This freedom is very useful to implementers in restructuring the package guts without impacting its design interface. Why not think about whether a goal of allowing hierarchical design is what you (Go designers) really want and if alias and internal packages are sufficient/necessary/the right way? -- 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.
