> Do you really think you are losing information if this becomes:
>
> func matches(p Policy, a authorizer.Attributes) bool {>From my point of view, yes it makes a big difference if I see a package-qualified identifier, because I know that it's invoking some other package's abstraction. I am very often traversing some code that I am not familiar with, and arbitrary names imported from external packages make that harder. It also makes it significantly harder to refactor code. In short, although there is a cost to qualifying external names, I believe that cost is justified. If you wish to lower the overhead of package qualifiers for frequently used names, there are alternatives to dot imports. You could specify a short (one or two character) identifier instead of the default package name. We do this a lot for some DSL-like packages. You could also define local type aliases - e.g. type policy = abac.Policy, or local function wrappers (mid-stack inlining should make that zero-cost at some point). FYI I have created a Go proposal related to this that you might wish to give feedback on: https://github.com/golang/go/issues/29036#issuecomment-443311975 On Sun, 2 Dec 2018, 5:59 am robert engels <reng...@ix.netcom.com wrote: > As some supporting evidence, here is a method signature in k8s: > > func matches(p abac.Policy, a authorizer.Attributes) bool { > > The interesting aspect is that this method is in package abac, except it > is in pkg/auth/authorizer/abac > > and the one being used in the method > > pkg/apis/abac > > Do you really think you are losing information if this becomes: > > func matches(p Policy, a authorizer.Attributes) bool { > > The developer needs to do mental work in either case. I left the > authorizer on purpose, because Attributes is too generic to be useful. > Granted, their package structure seems poor in my opinion, but you can’t > talk bad about k8s. > > Here’s an easier example from k8s: > > func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, > after time.Duration) { > > Is that any better than > > func (dsc *DaemonSetsController) enqueueDaemonSetAfter(obj interface{}, > after Duration) { > > And another: > > func deleteOwnerRefStrategicMergePatch(dependentUID types.UID, ownerUIDs > ...types.UID) []byte { > > Is that really better than: > > func deleteOwnerRefStrategicMergePatch(dependentUID UID, ownerUIDs ...UID) > []byte { > > > If you need a package named types, it is probably ubiquitous throughout > the codebase, so using type.UID everyplace is just noise. > > And probably the most common method signature of them all: > > http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) { > > are you losing anything if this is: > > http.HandleFunc("/bar", func(w ResponseWriter, r *Request) { > > I would argue you are actually gaining something, as the Request above > might be a facade with extra properties etc. The compiler will inform you > if you use an incorrect property, and an IDE will give you the > method/properties as you code, so its completely safe. Now, you might be > thinking, request is pretty generic, so this is not the best example > (because a web app probably has lots of different types of Request, and it > could quickly become confusing, but wait, the http.HandleFunc removes any > ambiguity. > > All coding requires good development choices - there are many times it > probably shouldn’t be used - but I making a blanket statement its bad > seems like overreach. > > > On Dec 1, 2018, at 11:19 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > 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. > > > -- > 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.
