Closed GoogleCodeExporter closed 9 years ago
I don't know how easy this is going to be to solve without full type
information. Taken in isolation, the Bar interface refers to a "Foo" type.
Where does that come from? It could be in the current package, but it could
also be from a dot import. It might be okay to assume the former. However, what
happens if it refers to "string"? That could be locally defined too.
Original comment by dsymo...@golang.org
on 1 Nov 2011 at 12:41
I see what you're saying, but this issue makes gomock effectively unusable for
a non-trivially large package that has interfaces that accept other interfaces
as arguments. How far out is the full type information?
Original comment by awre...@gmail.com
on 2 Nov 2011 at 5:17
Correction: The only way to use gomock is to avoid dot imports and to put the
mock objects in the same package as the actual objects (and thus export them to
external users of the library).
Original comment by awre...@gmail.com
on 2 Nov 2011 at 5:19
Can't you use auxilliary files to do a dot import of the original source
package? Then the generated mock referring to "Foo" would work.
Original comment by dsymo...@golang.org
on 3 Nov 2011 at 6:28
I'm not quite sure how that would work. The solution I've stumbled upon
involves naming mock objects _test.go so they aren't exported by godoc, but
that seems hacky.
https://github.com/awreece/golog/blob/master/Makefile
Original comment by awre...@gmail.com
on 3 Nov 2011 at 2:41
I think this is obsoleted by the reflect mode of mockgen.
Original comment by dsymo...@golang.org
on 5 Sep 2012 at 7:48
Original issue reported on code.google.com by
awre...@gmail.com
on 31 Oct 2011 at 9:52Attachments: