Relax File interface requirements

[sheerun]

This PR removes the requirement of File to implement Name() method.

Reasons:

1. Name doesn't always makes any sense (e.g. memfs)
2. Prevents issues with implementation of fs.Name(), e.g. in my implementation I normalized relative path to absolute path and passed it to underlying os.Create(name). Then os.Name() returned absolute path what got passed to fs.Open() implementation that expected relative path on input and failed miserably. In principle the result of Name() should be the same as passed to name of Create() or Open(), so it makes little sense for File to implement this method by itself.
3. I cannot think of use case someone wanted to implement this method in custom way
4. It makes it easier to implement backend
5. This change is 100% backward compatible

[djherbis]

I'm not confident this is a backwards compatible change since it removes a method. It might not break our library, but that doesn't mean it doesn't break clients of our library (and it does break some of those).

What if we did something like use path/filepath to normalize the paths even for the in-memory one?

I really appreciate the pull requests, though sometimes it might be worth discussing an idea (with an issue) before proposing the pull req.

[sheerun]

The removed method is on interface you don’t return anywhere. You only return io.Reader and io.Writer. The only place you use it is as parameter to writer constructor which means nothing will break even if someone defined this method.

It’s OK if you don’t merge I needed it in my fork

On Wed, 17 Jan 2018 at 19:33, Dustin H [email protected] wrote:

I'm not confident this is a backwards compatible change since it removes a method. It might not break our library, but that doesn't mean it doesn't break clients of our library (and it does break some of those).

What if we did something like use path/filepath https://golang.org/pkg/path/filepath/ to normalize the paths even for the in-memory one?

I really appreciate the pull requests, though sometimes it might be worth discussing an idea (with an issue) before proposing the pull req.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/djherbis/stream/pull/8#issuecomment-358381145, or mute the thread https://github.com/notifications/unsubscribe-auth/AAR2DR4254kBPomhckXEpae-ElIHwJjIks5tLi7ygaJpZM4RdwU_ .