- rework FilterFs to be truely chaining, i.e. every call not intercepted
must be passed to the source Fs
- AddFilter accepts just a FilterFs, not a Fs
- FilterFs' AddFilter(FilterFs) should be implemented by any
FilterFs like
func (f *myFilter) AddFilter(fs FilterFs) {
fs.SetSource(f.source)
f.source = fs
}
A few things are fixed by this commit:
- check error value returned from `fs.RemoveAll` in `removeAllTestFiles`.
- Defer statements are a LIFO, and were out of order in some test functions.
- The TestReaddir* funcs were failing to close some file handles.
- `findNames` was opening file handles but ignoring them. Bad.
I had to wrap the setupTestFiles() function for this test, one for returning the root of the test dir and the other one to reuse the path that was returned from the first function. If this is not done setupTestDir writes into two different folders that are returned from os.TempDir() and the output of the two walk functions can't be compared.
This is a BREAKING CHANGE to the Walk and ReadDir functions that
existed prior to this branch addition. This change is not done without
considerable thought.
Having FS come first is done for two reasons.
1: It's more idiomatic go
2: It's more logical. It allows the function signature to read easier
and flow from the broadest value to the most narrow.
For example, WriteReader would read..
writeReader on this fs, to this path (on that fs),
with this data (at that path, on that fs).
I believe that when the first two were implemented it wasn't at all
obvious that the order wasn't correct, nevertheless, permitting a
lot of new functions defined in an incorrect or inconsistent order
seems like the worst option.
It was decided that a breaking change today would be best, even if it
was mildly painful at the present.