I agree that is an important consideration, but it seems less important if the packages are small and focused.
I think an important point to consider is that there are systems apps, and enterprise apps. These rules seem well suited to systems apps, but maybe not so well suited to business enterprise apps. As I become more familiar with Go I become more convinced that is great for systems apps, and not very workable for business apps. I’m trying to work on some things that might change the latter, but to get there I’m trying to fully understand the thinking behind these design decisions. > On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor <i...@golang.org> wrote: > >> On Sat, Dec 1, 2018 at 7:25 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> The way to fix it though it just to use dot imports, and encourage it! The >> only time dot imports don’t work is when there isn’t package stutter. Seems >> like a no brainer and you get the best of both worlds. > > Go programs that do not use dot imports have the convenient feature > that any unqualified name must be defined somewhere in the same > package. The first component of any qualified name must be either > defined in the same package or be the name of a package imported in > the same file. These convenient facts make it easier to read Go code > and quickly understand where each name is coming from. > > Ian -- 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.
