Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kitgen implementation #589

Merged
merged 123 commits into from
Dec 3, 2017
Merged

kitgen implementation #589

merged 123 commits into from
Dec 3, 2017

Conversation

nyarly
Copy link
Contributor

@nyarly nyarly commented Jul 31, 2017

So far what I've got is simple generation based on a basic interface definition.

Not complete: different layout engines.

Specific design decision here was to construct the generated AST and then
format it out, as opposed to using a text/template. There's some things that
are made much easier this way (i.e. the output is more likely to be correct
code), but the generation code is a bit more opaque. In working with this
process I've found a few things that make the process clearer, and I'm looking
to implement those before this is merged. Specifically, I think many of the
repeated structures could be snagged from an example codefile and then
processed into target structures, rather than built out of whole cloth or
partial inline parses.

@nyarly
Copy link
Contributor Author

nyarly commented Aug 2, 2017

I'll be proceeding with this, but I wanted to get a little oversight to see if it's in a useful vein, @peterbourgon

@peterbourgon
Copy link
Member

Ah! I missed the notification! This is great. Let me dig in later today and I'll give some more specific comments...

@peterbourgon
Copy link
Member

peterbourgon commented Aug 3, 2017

Yeah, this is badass. Pretty much exactly what I had in mind, modulo the parameterization that you've already acknowledged. I also noticed it panics when I don't name the parameters in my service definition, i.e.

type Service interface {
    Foo(context.Context, int, int) (int, error)     // panic
    Bar(ctx context.Context, i, j int) (int, error) // OK
}

If you have enough to move forward, great! If not, please let me know how I can help: clarifying, requirements-gathering, etc.

@peterbourgon
Copy link
Member

peterbourgon commented Aug 3, 2017

Hehe, fun!

$ cat test.go
package main

import "context"

type Service interface {
	Foo(_ context.Context, _ int) (int, error)
}
$ kitgen test.go
 ...
func (s stubService) Foo(ctx context.Context, _ int) (int, error) {
        return "", errors.New("not implemented")
}

type FooRequest struct {
        _ int
}
type FooResponse struct {
        I   int
        Err error
}

func makeFooEndpoint(s stubService) endpoint.Endpoint {
        return func(ctx context.Context, request interface{}) (interface{}, error) {
                req := request.(FooRequest)
                i, err := s.Foo(ctx, req._)
                return FooResponse{I: i, Err: err}, nil
        }
}
 ...

@nyarly
Copy link
Contributor Author

nyarly commented Aug 3, 2017

I'm good. Just wanted to make sure I wasn't running down a rathole. :)

The edge cases are great. Thanks!

@nyarly
Copy link
Contributor Author

nyarly commented Dec 1, 2017

Okay - there's the rebase 🤞

@peterbourgon peterbourgon merged commit 53f10af into go-kit:master Dec 3, 2017
@peterbourgon
Copy link
Member

Woohoo!

@zkanda
Copy link

zkanda commented Dec 4, 2017

I've been trying it out and it works great, thank you @nyarly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet