Add support for generics #44
Comments
|
Maybe I'm missing something, but |
|
Sorry, this probably would've been more helpful with an example, huh? type Parser[Result any] interface {
Parse(in []byte) (Result, error)
}That's valid in Go 1.18, but I can't use I would expect it to generate (assuming it was run with func (s stringParser) Parse(in []byte) (string, error) {
panic("not implemented")
} |
|
Ah! I see. So you'd also have to tell I see the usefulness, although I'm a bit worried about the command line API. There can be an unlimited number of type parameters. Using order isn't a great API, but naming them gets awkward. At some point it'll be easier to write the implementation stubs by hand. :P I'm not spending much time on impl at this point. If there's a path forward that is simple and clear, I'm happy to review it. If not, I will probably wait until popular demand grows larger. :) |
|
So I think my preferred way of invoking it would be to just attach the type parameter to the interface type. I don't use I don't know what the command line equivalent is, sadly. :( But the above could read that it wants a I haven't looked at |
|
That works for me. I would review such a PR, with the caveat that my turnaround time is typically O(weeks) or even O(months). I'm not proud of that...just being honest. |
|
The transparency is appreciated and no judgment. Appreciate the willingness to look at it, if I (or someone else) can find the time and energy to put something together :) |
Update go.mod to indicate support for Go 1.19.
Add support for generic interfaces, i.e. interfaces that accept a type
parameter.
For example, you can now have this kind of interface:
```go
type Interface[Kind any] interface {
DoTheThing() Kind
}
```
and if you run `impl 's StringImpl' 'Interface[string]` it will generate
the following code:
```go
func (s StringImpl) DoTheThing() string {
// normal impl stub here
}
```
Fixes josharian#44.
|
I've opened #49 with my implementation of this feature. I've added some test cases, but was unable to get a test case for a qualified interface working in an automated fashion; the full path worked, and the unqualifed interface worked, but the qualified one couldn't find the testdata package. I have verified it manually, though that's not ideal and it has only been tested with an interface that accepts two type parameters (that's all I had handy). |
Update go.mod to indicate support for Go 1.19.
Add support for generic interfaces, i.e. interfaces that accept a type
parameter.
For example, you can now have this kind of interface:
```go
type Interface[Kind any] interface {
DoTheThing() Kind
}
```
and if you run `impl 's StringImpl' 'Interface[string]` it will generate
the following code:
```go
func (s StringImpl) DoTheThing() string {
// normal impl stub here
}
```
Fixes josharian#44.
Update go.mod to indicate support for Go 1.19.
Add support for generic interfaces, i.e. interfaces that accept a type
parameter.
For example, you can now have this kind of interface:
```go
type Interface[Kind any] interface {
DoTheThing() Kind
}
```
and if you run `impl 's StringImpl' 'Interface[string]` it will generate
the following code:
```go
func (s StringImpl) DoTheThing() string {
// normal impl stub here
}
```
Fixes josharian#44.
Add support for generic interfaces, i.e. interfaces that accept a type parameter.
For example, you can now have this kind of interface:
```go
type Interface[Kind any] interface {
DoTheThing() Kind
}
```
and if you run `impl 's StringImpl' 'Interface[string]` it will generate
the following code:
```go
func (s StringImpl) DoTheThing() string {
// normal impl stub here
}
```
Add a Type abstraction, make type parsing more robust.
Instead of parsing generic types using string manipulation, parse them using the go/parse package to get the AST.
Rather than passing around a type ID and its params everywhere, create a Type struct that contains both.
Fixes #44.
Co-authored-by: Josh Bleecher Snyder <josharian@gmail.com>
With the release of Go 1.18, interface types can now have type constraints. It would be neat to be able to specify these type constraints when generating the implementation.
The text was updated successfully, but these errors were encountered: