Exposing FileStorage methods for external use

[AbelToy]

I am writing a feature that saves user images to disk.

While I could write an equivalent of FileStorage to make it testable, it would be really helpful if I could just rely on defaultFileStorage to save the file directly.

I don't want to go through @Shared since I definitely do not want to keep the file in memory.

[pyrtsa]

Exposing the methods of FileStorage would also help tremendously when testing file-backed @Shared or @SharedReader usage.

While FileStorageKey is able to observe changes to the underlying filesystem, there's currently no way to write unit tests on in-memory FileStorage because the only way to interact with FileStorage.inMemory is through the Shared API (which is even partly asynchronous even if the file operations aren't).

I'm thinking opening a PR to change this.

[stephencelis]

Can you explain more, or maybe start a new discussion? We believe the implementation of FileStorage should mostly be opaque, and the internals are there mostly for our own testing. Generally we don't think folks should be maintaining external test suites against these implementation details, and if there is an issue with our implementation ideally it is tested/fixed in our library, not tested in someone's external library.

If you truly need end-to-end/integration tests against a fileStorage-backed shared value, it should be possible to do so without any FileStorage interactions.

[stephencelis]

@AbelToy A locally-scoped @Shared will either share an existing reference or be deallocated as soon as its scope ends. So you should feel free to use @Shared to make writes to an external file without worrying about it staying in memory.