Closed
Description
In the go.tools repo, godoc/vfs/vfs.go defines a very useful FileSystem type:
type FileSystem interface {
Opener
Lstat(path string) (os.FileInfo, error)
Stat(path string) (os.FileInfo, error)
ReadDir(path string) ([]os.FileInfo, error)
String() string
}
type Opener interface {
Open(name string) (ReadSeekCloser, error)
}
type ReadSeekCloser interface {
io.Reader
io.Seeker
io.Closer
}
There are other useful packages in go.tools (and elsewhere on GitHub) that make use of
FileSystem interface implementations.
But the fact that ReadSeekCloser is a named type makes it impossible (as best I can
tell) to implement vfs.FileSystem in an external package without importing vfs (and thus
pulling down the whole go.tools repo). This goes against the spirit of implicit
satisfaction of interfaces.
For example, I created a package (https://sourcegraph.com/sourcegraph/go-vcs) that
implements an almost identical interface to vfs.FileSystem, but to avoid adding go.tools
as a dependency, I copied the 3 above types to my package. Now people want to use my
package's VCS FileSystem implementation with other godoc/vfs/... packages, and they
can't (see sourcegraph/go-vcs#11.
I believe that vfs.FileSystem is an extremely useful building block, and it would make
it much easier if people could build interchangeable implementations of it without
importing go.tools. (As an aside, we use it in multiple places at Sourcegraph, and
Jeremy Saenz mentioned it on stage at dotGo as a "hidden gem".)
Would you consider any of the following solutions?
1) Changing godoc/vfs's (Opener).Open method to return
(interface{io.Reader;io.Seeker;io.Closer},error) instead of creating a separate named
ReadSeekCloser type (external packages could satisfy the interface by simply using the
anonymous interface type)
2) Adding ReadSeekCloser to the stdlib as io.ReadSeekCloser