reflect: MakeInterface

[bradfitz]

Feature request for MakeInterface, to go along with the newly-arrived MakeFunc (Issue
1765).

Good goal would be gomock without source code generation.

[rsc]

Comment 1:

Labels changed: added priority-later, go1.2.

Status changed to Accepted.

[dsymonds]

Comment 2:

Yes, this would be marvellous for GoMock.

[bradfitz]

Comment 3:

While we're listing use cases, I'd also be able to take an arbitrary http.ResponseWriter
value from a client (which may implement optional http.Hijacker and/or io.WriterTo
and/or http.Flusher) and change a method or two on it, while still forwarding all other
methods on it.
Currently whenever I want to implement an http.ResponseWriter wrapper (which I continue
to do regularly), I have to defensively implement all 3 optional interfaces, with the
implementation bodies checking at runtime whether the wrapper ResponseWrapper implements
those, otherwise I break people's flushing or sendfile or hijacking, when perhaps all I
want to do is record Writes that go by, or change the underlying transport, or watch for
errors, etc.
Doing something like:
type myWrapper struct {
    io.Writer
    http.ResponseWriter
}
... is an error, due to Write ambiguity, and something like:
type myWrapper struct {
    http.ResponseWriter
}
func (myWrapper) Write([]byte) (int, error) { ... }
... hides Flush, WriteTo, Hijack, etc.
I could see where this road leads to abuse and performance problems, though.
But it's painful either way.

[rsc]

Comment 4:

It is unclear to me why this would be enough to eliminate Go file
generation from GoMock. The implementations of preexisting interfaces
could be generated this way but not the mocking stubs that people call
to describe the expected call sequences.
Russ

[dsymonds]

Comment 5:

It wouldn't eliminate the code generation, but it would halve it. That would be nice.
Eliminating the rest would require run-time type construction, which is outside the
scope of this issue.

[rsc]

Comment 6:

Eliminating half the generation for gomock may be compelling for you
as the author but it doesn't change at all the way people interact
with gomock. It's still a separate preprocessor. I'd be much more
excited if we could get rid of all the Go file generation entirely.
That's a qualitative difference.
However, even with runtime type construction I don't believe you can
eliminate the other half. You need something at compile time for the
mock user to import.
Russ

[dsymonds]

Comment 7:

You don't. The existing API for GoMock generated code only exports the
mock implementation of the interface; the recorder is returned by an
EXPECT method on that. I don't see any reason why something needs to
be imported. Instead of
  foo := mock_foo.NewMockFoo(ctrl)
you could write
  foo := gomock.NewMock(ctrl, (*Foo)(nil)) // passing a pointer to the interface
and get back a dynamically created mock.

[rsc]

Comment 8:

Yes but keep going. What does the code using foo look like? Suppose it
says foo.EXPECT(). The compiler must see a definition of a struct or
interface with an EXPECT method at compile time in order to build
that. Where did that come from? Here's a line from
sample/user_test.go:
        mockIndex.EXPECT().Put("b", gomock.Eq(2)) // matchers work too
I don't see how the compiler can compile that line without a
gomock-generated import defining something with a Put method that will
accept gomock.Eq(2) as an argument.

[dsymonds]

Comment 9:

Aah, I see where you're going. I was imagining that those methods
could be changed to take (...interface{}), and do type checks at run
time, but that still doesn't solve the very existence of EXPECT, and
nor does the compiler know about the existence of its return type's
Put method.

[extemporalgenome]

Comment 10:

That 'qualitative difference' can also be achieved by other means, such as build tool
support for custom pre-compilation phases, possibly specified by build directives (e.g.
a // +prebuild comment in GoMock could specify that the GoMock preprocessor be run on
anything that imports the mocking package).

[rsc]

Comment 11:

Not going to make the Go 1.2 cut. Not clear there's a use case anyway.

Labels changed: added go1.3maybe, removed go1.2.

[robpike]

Comment 12:

Labels changed: removed go1.3maybe.

[rsc]

Comment 13:

Labels changed: added go1.3maybe.

[rsc]

Comment 14:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 15:

Labels changed: added repo-main.