Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/gopls: generate method stubs for a given interface #37537
It would be great if Gopls implemented a way where a user:
See this video for a demonstration: https://vimeo.com/394345925
A common feature that Go and other typed languages have is to generate method stubs for an interface that a type wants to implement.
For most languages, the concrete type must declare what interface it intends to implement. This makes it easier for tools to generate those stubs.
For an example, take a look at this screenshot from TypeScript in VSCode:
In Go, it is impossible to know that because interfaces are implicitly implemented.
Therefore, generating method stubs require a two step process:
Therefore, I wrote a tool that that can do both of these features: https://github.com/marwan-at-work/impl
Here's a video of how I integrated the tool with VSCode locally to demonstrate the same feature working for Go: https://vimeo.com/394345925
However, the tool uses go/packages directly and is obviously a standalone that doesn't leverage gopls with its cache and environment. Therefore, I suggest we make this a feature within gopls.
If this is something worth including, I'd be very happy to port the work I did into gopls (with a little help).
Unfortunately, the LSP protocol does not have an explicit message for "generating method stubs", and so we a few options were brought up in slack that I want to highlight here:
PS. Note that this tool used to exist in GOPATH mode using https://github.com/josharian/impl but as far as I know, it is not modules aware and lacked a number of features such as "listing available interfaces" and "automatically adding import paths"
Another possibility would be to add it as a quick fix to the
type checking error.
stanza if needed.
@ianthehat Would it be possible to expand it to wherever a concrete type is being casted as an interface? For example:
Similar to rename, it should only do it if the concrete type was defined within the workspace/module boundaries.