example is a bit contrived. I've written a good amount of Go code and I
have yet to find an instance of this problem.
Regarding speed improvements, which seems to be what the majority of people
want to achieve, it would do next to nothing.
On Friday, May 15, 2015 at 1:24:13 PM UTC+1, Ian Davis wrote:
On Fri, May 15, 2015, at 01:15 PM, Alberto García Hierro wrote:
That would work, but it would break a lot of editor plugins which are just
passing the input using stdin without the filename. I don't think breaking
goimports is worth it (specially, since it's intended as a gofmt
replacement and the latter also works with just stdin, no filename), but
that's not my call to make. Also, it might be desirable to keep
tools/imports (where +90% of the execution time of goimports is spent) able
to work only on memory, with no filesystem available.
In any case, teaching goimports about other identifiers in the same
package feels like a bandaid solution to me. It would be better to just
make it fast at finding Go packages and the other issues would just go away
(if you take finding Go pkgs out of the equation, goimports takes less than
a few milliseconds to do its job).
It's not a bandaid, it would address a real problem that makes goimports
much less useful than it could be. Example: if you have a package level
variable called log then goimports attempts to add "log" as an import.
It means you can't have package level variables that might conflict with
any package name in your GOPATH.
Ian
--On Fri, May 15, 2015, at 01:15 PM, Alberto García Hierro wrote:
That would work, but it would break a lot of editor plugins which are just
passing the input using stdin without the filename. I don't think breaking
goimports is worth it (specially, since it's intended as a gofmt
replacement and the latter also works with just stdin, no filename), but
that's not my call to make. Also, it might be desirable to keep
tools/imports (where +90% of the execution time of goimports is spent) able
to work only on memory, with no filesystem available.
In any case, teaching goimports about other identifiers in the same
package feels like a bandaid solution to me. It would be better to just
make it fast at finding Go packages and the other issues would just go away
(if you take finding Go pkgs out of the equation, goimports takes less than
a few milliseconds to do its job).
It's not a bandaid, it would address a real problem that makes goimports
much less useful than it could be. Example: if you have a package level
variable called log then goimports attempts to add "log" as an import.
It means you can't have package level variables that might conflict with
any package name in your GOPATH.
Ian
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
