pkg
Proposal: (*File).Readdir(n int) ([]os.FileInfo, error)
The closer this library matches the os.File object the more easily functionality can be wrapped with interfaces.
The (*Client).ReadDir(path string) ([]os.FileInfo, error) should probably also include an "n int" parameter as well?
client.ReadDir(path) was modeled after ioutils.ReadDir(path), not os/File.ReadDir(int).
The sftp client library currently doesn't have an equivalent to os/File.ReadDir(int). The client library isn't built around the idea of the using the File object for directories, so adding that method would require quite a lot of work. It doesn't seem to me that not having it would mess with your ability to create an interface for File objects with the subset of matching functions.
So I don't think this necessary. I'll give you a chance to give a counter point before I close the ticket.
Ah, then yes, the client.ReadDir definitely shouldn’t change.
If one does not immediately read the data, a sftp/File.ReadDir(int) should just need to call client.ReadDir(f.Stat().Name()) and then subslice it as necessary.
The idea was just to add parallels to existing libraries. If the method is now considered “poor” or “ill” designed now with 1.9 hindsight upon the original Go1 library, then yeah, no reason to copy it.
I don't think the File.ReadDir() is deprecated or anything, it is just a different way vs the ioutils list method.
As for an implementation, I think it'd need to be a bit more than what you suggest. While that would work, it would be inefficient to pull down the full list each time only to slice a segment of it. The inefficiency would be particularly appalling given the underlying protocol works in a way very similar to the way the File.ReadDir() works.
I'm not saying no... just saying it would need to be a better mapping to the underlying protocol. Given that it is mostly duplicate functionality I'm not going to make this a top priority. But it might be fun to see just how well the API and the protocol line up. For the moment it is a definite maybe.
Yeah, makes sense. And my quick-and-dirty was the “get it working, then optimize it later” idea. Not meant to be anything long term.
But then everything that is explicitly meant to be temporary is always permanent, right?