|
|
|
|
|
|
by AdhemarVandamme
671 days ago
|
|
|
I like this idea. My first remark is VirtualStorage<T>. As I understand it, T is the type the library user can associate with the items (nodes, files) of the tree. I think this library can be made more useful with VirtualStorage<T, U> where U is a type you can associate with the directories of the tree. VirtualStorage<T> is then equivalent with VirtualStorage<T, some-dummy-unit-type>. (If I'm not mistaken, F# allows unit where a type parameter is expected, but C# does not allow void.) The use case I have in mind has been mentioned in other comments as well: keep a representation of a file system in memory. For such use cases, you could then use VirtualStorage<System.IO.FileInfo, System.IO.DirectoryInfo> But also in other use cases, associating information at the directory level might be very useful. Going even further, maybe a third type might be associated with links as well? |
|
|
The idea of using VirtualStorage<T, U> is very interesting. Currently, the class representing a directory is of the VirtualDirectory type, which is not a generic type. I think the idea of making directories a generic type, VirtualDirectory<U>, to encapsulate a user-defined type U, similar to how VirtualItem<T> represents items, is very useful. Consequently, it would allow us to comprehensively manage everything as VirtualStorage<T, U>.
With your proposed approach, when using VirtualStorageLibrary to represent a file system in memory, it would be possible to create an instance of VirtualStorage<T, U>. This would intuitively allow for the retention of information about physical files and directories.
The key feature of this use case is that it allows for efficient reference and traversal of nodes in a file system maintained with VirtualStorage<T, U> through the VirtualStorageLibrary API. However, implementing node operations (deletion, moving, copying) presents some challenges. This is because, when performing node operations, it is necessary to update the System.IO.DirectoryInfo held within VirtualDirectory<U>. This implies that there would be overlapping node operations between the node manipulations in VirtualStorageLibrary and those in System.IO. Given this, it seems more practical to focus solely on efficient node referencing and traversal in this use case.
The idea of associating a third type with VirtualSymbolicLink in VirtualStorageLibrary might require further consideration, but it certainly seems worth exploring.
Thank you for sharing such meaningful and interesting ideas. If you would like, please consider posting your ideas in the issues or discussions on the VirtualStorageLibrary repository.
VirtualStorageLibrary GitHub: https://github.com/shimodateakira/VirtualStorageLibrary