3. We want to be resilient when other methods are added to the DatastoreClient interface so that the code will still compile when that happens.
That was my guess too: that it's a tradeoff between safety and future compatibility. This allows your library users to use newer versions of the protobuf dependency, without forcing the library to be updated by the library author or the library dependency to be bumped by the user. On the other hand, so would embedding the interface anonymously, but maybe the failures are more subtle if you accidentally call a method you didn't account for (e.g., in this case, no headers are passed). However in fact, there appears to be no need (*) for the datastoreClient type to implement pb.DatastoreClient at all The unit tests depend on this being an interface that can be faked; I guess this avoids having to create your own interface for the subset of methods you're calling on the client. It would also enable library users to pass their own client, although this doesn't seem to be possible using the API. thanks, Remko -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7cef7f85-6760-4f42-bd24-46e495a711fen%40googlegroups.com.
