I prefer the first line to the second, even though it requires a dot import.
*Sin*(*Pi*/2)**Sin*(*Pi*/2) + *Cos*(*Pi*)/2
*math.Sin*(*math.Sin*/2)**math.Sin*(*math.Pi*/2) + *math.Cos*(*math.Pi*)/2
But of course in this case there is an even better solution. :)
*0.5*
On Wednesday, April 4, 2018 at 11:30:22 PM UTC+2, rog wrote:
>
> On 2 April 2018 at 15:42, Paul Jolly <pa...@myitcv.io <javascript:>>
> wrote:
> > Speaking as someone who has written a few (albeit simple) code
> generators
> > that parse Go code, dot imports are a nightmare from my perspective
> because
> > it makes it impossible to work out from just imports alone whether an
> > identifier belongs to the current package or not.
> >
> > Put another way, if you disallow dot imports, a reference to anything
> that
> > is outside the current package needs to be a qualified identifier, a
> > qualified identifier that is easily determined by reference to the
> (possibly
> > renamed) imports in the current file.
> >
> > Blank imports on the other hand are only used for the side effects of
> their
> > inits; they do not alter the importing scope.
> >
> > I can't quite find the link right now, but it has long been thought/said
> by
> > the authors of the Go language that dot imports should not have been
> > included in the language.
> >
> > All that said I suspect this was a large part of the reason that golint
> > discourages the use of dot imports.
>
> I agree wholeheartedly with this. In my experience they are almost
> used for aesthetic reasons ("the package-qualified names ruin the look
> of my DSL!") and those reasons should not trump the overall
> readability and maintainability gains from having all externally
> declared variables properly qualified.
>
> If you want minimal package qualification for very frequently used
> packages, using a shortened package identifier can work well. For
> example, we commonly import our testing helper package with a
> two-character package identifier because its symbols are so commonly
> used. A single capital letter could work well too, I think.
>
> We now also have aliases if you want to define names locally, but
> that's an avenue I haven't explored much, and might turn out to be a
> bad idea in the long run.
>
> I'm rarely an absolutist when it comes to programming style, but I
> make an exception for dot-imports. Please don't succumb to their
> temptation.
>
--
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.
