I am not referring to variable declarations I am referring to
X := SomeFunc()
Far worse for understanding than having common or ubiquitous structs as dot
imports. That way they become “part of the language”
Static imports were added to Java long ago and if Java guys can figure it out I
think you can too. It makes constants and ubiquitous types far easier to work
with.
And since you like lingo, more bits of information is not always a good thing.
That’s why we have compression, and lossless compression of fixed.Fixed to
Fixed is pretty good in my book.
> On Nov 29, 2018, at 8:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
> On Thu, Nov 29, 2018 at 3:07 PM Robert Engels <reng...@ix.netcom.com> wrote:
>
> > Wait, you support type inference and not dot imports... I think you should
> > revisit this opinion...
>
> I believe it's the other way around. Seeing T alone has n bits of
> information. Seeing foo.T carries more bits of information. So Seeing
>
> x := foo.T{}
>
> for example, tells me about everything what I need to know when I already
> know what is and why I or anyone else imported package foo.
>
> OTOH, "naked" T from an imported package loses that information and requires
> to additionally build a mind map from T to foo. That's arguably not simpler.
>
> > also, dot imports are very versatile when changing the implementation
> > without changing a lot of LOC.
>
> Well, then I hope your code reviewer does not share my opinions about dot
> imports ;-)
>
> BTW: Neither are dot imports allowed inside the Go project itself. IINM, the
> only exception are tests that were written before the build system (the go
> command) existed.
>
>
> --
> -j
--
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.
