I know everyone hates it when I reference java but it has had dot imports at the package level since day one. I won’t repeat why that matters. It’s never been a problem.
I don’t think I ever heard someone complain it was a problem in working in Java, why is it such a problem in Go? I’m suspecting it’s because people’s packages are too large in scope so they end importing tons of external packages. It’s a structure problem not a language feature problem. > On Dec 1, 2018, at 11:08 PM, Ian Denhardt <i...@zenhack.net> wrote: > > Quoting Robert Engels (2018-12-01 22:25:06) > >> 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. > > My experience in every language I've worked with that has an equivalent > of dot imports has been: this is more trouble than it's worth. It hurts > readability of large codebases more than any other single language > feature I can think of, and this has been my experience in everything > from Python to Haskell. > > It is sometimes nice for DSLs -- Elm has an Html module that just > defines a function per html element, and folks usually "dot import" > that whole module. But they basically never "dot import" *anything* > else, and doing it in the general case is similarly discouraged. In > languages where I've seen *common* use of it, I've come to the > conclusion that it basically doesn't scale beyond one package, which > has to be something that everyone in the language community knows well. > In Elm it's Html. In Go it's the set of built-in identifiers. That's all > we get. > > --- > > There really is something special about a package's "main" type here > (when it has one) that makes the stutter a bit hard to work around > sometimes. It's a bit unfortunate to have to write context.Context, but > nothing *else* in the context package has this problem. Much of the > OCaml community has gone with the convention of just calling the type > 't' and using the module name to distinguish, and it works pretty well. > > In Elm you see a lot of this: > > import Json.Decoder exposing (Decoder) > > ..which imports the Decoder type from that module unqualified, and > leaves the rest qualified. > > I find it a bit unfortunate that the stuttery approach to naming primary > times has ended up being the norm in Go, but I do think idiom is worth > something; doing pkg.T is a little surprising to me when reading Go > code, even though it isn't when reading OCaml. > >> People say, it makes things less clear, and I counter that variable >> inference is far worse and it's done for the sake of less verbosity, >> and people love it... > > I don't think we're going to agree on this point any time soon, so I'll > just say: this does not square with my own experience. > > -- > 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.
