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.
