Since the purpose of this is apparently to provide a fake structure to test against - would another viable approach have been to implement a trivial `Close` function that doesn't do anything?
(context: i am no gopher)
(edit/tangent: i wonder how method calls from inside method calls are resolved when the names are ambiguous?)
You need quite a few more method to be a net.Conn actually: http://golang.org/pkg/net/#Conn. Easier to just overwrite the Write() method like this in that case.
If you just need a close that does not do anything, go has a pretty cool wrapper: `ioutil.NoopCloser`. It takes a reader and returns a reader that can be closed `io.ReadCloser`. Very useful for testing/mocking
Comments
Since the purpose of this is apparently to provide a fake structure to test against - would another viable approach have been to implement a trivial `Close` function that doesn't do anything?
(context: i am no gopher)
(edit/tangent: i wonder how method calls from inside method calls are resolved when the names are ambiguous?)
You need quite a few more method to be a net.Conn actually: http://golang.org/pkg/net/#Conn. Easier to just overwrite the Write() method like this in that case.
I suspect your tangent is because you don't fully understand how composition works. Basically, it's weaker than you think I believe.
I tried to write an example that demonstrates why I don't think the ambiguity you're referring to is possible.
https://play.golang.org/p/TyMJbOjDdZ
If you just need a close that does not do anything, go has a pretty cool wrapper: `ioutil.NoopCloser`. It takes a reader and returns a reader that can be closed `io.ReadCloser`. Very useful for testing/mocking