2026/06/19
|
Friday, June 19, 2026 (#170)
|
|
References |
Main Work
- Ferreteria FileSys stuff in order to support sftp in FTM.
Yesterday I ended up in a place where some restructuring of the FileSys spex subsystem was needed. Having gotten that to a certain point, I'm now running into a situation where a new method – Node::NodeForEntry() – generates an error in a podling class (Wild) which inherits Node's interface but not its class, for reasons.
Further investigation into how best to rectify this revealed the need for some restructuring around Node-object management, in part because of some duplication of effort:
All of these things have functionality which manage a list of Nodes and can iterate through it. They all need to be reconciled, somehow, so that Sys\FileSys\Node\Wild and Sys\FileSys\Node\Fo can use the same NodeForEntry() and have the same API for retrieving list-entries.
Tentatively, what is needed is an auxiliary class just for handling the list -- possibly just an expansion of Iter -- which would then be used as an object by Fo and Wild (which maybe will get relocated).
The first question I'm bumping into: should the work be done by Iter (meaning we'd have different implementations (class-podlings) of it), or should Iter be more of a collection/list utility-class which the various host-objects use as needed?
21:34
Actually, there's a subtle difference between Iter's scope and Nodes's scope: the former lets you iterate through a list without loading every element first (necessary for handling very large directories), while the second specifically requires loading all elements at once for sorting.
Perhaps we want sorting to be optional, and only used in certain circumstances where we're expecting the list to be of manageable size. We could then use the same class, but just de-serialize the list into an array when explicitly requested.