-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FileTree abstraction #11
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #11 +/- ##
==========================================
- Coverage 75.96% 72.37% -3.60%
==========================================
Files 34 35 +1
Lines 1577 1712 +135
Branches 263 286 +23
==========================================
+ Hits 1198 1239 +41
- Misses 326 420 +94
Partials 53 53
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
Needs tests |
- Value not being nullable in case of value types like interger - Use recursion in FindNode
Tests are done, should be ready for review. Let me know of any functionality you might want added or different. |
Additional functionality that MO2 has on its IFileTree abstraction:
Any of these that we would like to add to our version? |
This PR adds abstractions for file trees, as detailed in this issue: Nexus-Mods/NexusMods.App#553
IFileTree
interface defines a set of common functionalities.FileTreeNode<TPath, TValue>
defines a generic implementation ofIFileTree
, where the contained paths are Type agnostic and where each File entry contains an associated generic TValue.To allow
FileTreeNode
to be path agnostic a newIPath<TConcretePath>
was added, with the intent have it be be implemented byAbsolutePath
,RelativePath
andGamePath
.The main objective of this new interface is to define a set of common functionality for path types, while still allowing these methods to return concrete path types instead of
IPath
.The problem with using
IPath
directly are Boxing allocations, since all Path types are implemented through structs.To avoid any boxing/unboxing, the code had to heavily rely on generics, making sure to always reference concrete types rather than interfaces.
A limited number of common methods where added to
IPath<TConcretePath>
, but this quickly revealed a number of inconsistencies betweenAbsolutePath
andRelativePath
.Most of these come from the special handling that Root folders require.
It should be noted that trying to deal with them in an abstracted way was quite frustrating. Each type has its own set of methods, only some of them implemented on both types, without a common interface to define them and with some of them having different meanings or semantics.
All the common functionality is in PathHelpers, which only deals with strings and requires an OS object for each method, making using it very unwieldy.
There is an open issue for this here: #10