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.

Reply via email to