You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off: Thanks for some great tools. Recently had the pleasure integrating fillstruct into vscode and now considering doing the same with fillswitch :)
While trying it out I noticed that it builds a complete GOPATH import graph, something that fillstruct does not — which makes the command take an order of magnitude longer to execute.
fillstruct builds the reverse import graph in order to catch as many packages containing types needed for the completion.
Example:
Consider there is package foo defining an interface I.
The type switch statement the user wants to fill is also in package foo and switches over a variable of type I.
package foo
type I interface {
M() U
}
type U int
func F(i I) {
switch i.(type) {
// invoke fillswitch here
}
}
Also, there is package bar importing package foo and containing a type implementing the interface foo.I.
package bar
import "foo"
type T struct{}
func (T) M() foo.U { return 0 }
By omitting the code section you referred to, the user will not get the completion for type bar.T.
However this is also incomplete, there might be another package (neither importing nor imported by package foo) in the GOPATH containing a type which implements the interface foo.I.
So there is a trade-off between speed and completeness.
If this setting stated in the example above is a corner-case, we might as well omit building the reverse import graph and have a faster tool. What do you think?
First off: Thanks for some great tools. Recently had the pleasure integrating
fillstruct
intovscode
and now considering doing the same withfillswitch
:)While trying it out I noticed that it builds a complete
GOPATH
import graph, something thatfillstruct
does not — which makes the command take an order of magnitude longer to execute.reftools/cmd/fillswitch/main.go
Line 184 in ed200a5
Is there a specific reason for having this in
fillswitch
and notfillstruct
? I naively tried removing it and it worked just fine without.The text was updated successfully, but these errors were encountered: