Closed infogulch closed 1 year ago
I agree that it would be ideal to use the same interfaces and types as io/fs
.
Unfortunately, as you've noted #49 adopted interfaces from a draft version of that design which doesn't match the final design. It isn't clear to me that we can change this in-place now without breaking existing callers that may have implemented tfconfig.FS
.
A type cannot implement both tfconfig.FS
and fs.ReadDirFS
at the same time because they both use method name ReadDir
but with different return types. Therefore I think we may need to define some sort of bridge implementation so that existing callers can keep using tfconfig.FS
while new callers can use fs.FS
.
It isn't clear yet what the best design would be for that, but the key requirement is that tfconfig.LoadModuleFromFilesystem
must keep expecting tfconfig.FS
. Hopefully it's possible to write a tfconfig.FS
implementation that wraps a fs.FS
and translates to the corresponding functions in io/fs
.
The fs.FS interfaces have been published in Go 1.16. I suggest updating the interface definitions defined in
filesystem.go
to align with the finalized design of FS.This project defines custom FS/File interfaces (reproduced below) that match an early draft of the FS interface design. I'm happy to see the attempt to match the coming spec, but unfortunately the spec had a few changes between the referenced draft and final design. Luckily it seems that the draft was still pretty close and I expect would require minimal changes to conform.
Thoughts?