2026/05/06

From WoozleCodes
< 2026 | 05
Jump to navigation Jump to search
Wednesday, May 6, 2026 (#126)
Tuesday Wednesday Thursday posts:prev <this> next

References

FTM update

  • 13:40 The current soft-blocker is that I need to figure out how to re-implement sequential numbering for a list of nodes in a folder, which was formerly handled by a now-retired class.
    • What I'm wondering is if the whole «[get list] ⇒ [sort list] ⇒ [iterate through list]» process can be encapsulated outside of Spider, at the folder-node level.
    • Since the [get list] process is handled by Node->InOut()->ContentArray(), maybe this belongs in InOut?
    • Also, a count-index needs to be added somewhere.
      • The end-result of the operation is a list of Pair objects. The index was originally in what is now the FSLink class, but it makes sense to me to have the Pair class as kind of "pair of FSLink objects with additional info".
      • ...except then it can't be encapsulated by InOut without providing additional info, i.e. the Dest FSLink object. Solutions:
        • (1) Obvious: put the index into FSLink instead.
        • (2) Sloppy: provide the Dest FSLink when requesting the list.
        • (3) Consider: encapsulate the listing process in the Pair class?
          • That process would go like this:
            • Get $this->OLinkA->ToNode()->InOut()->ContentArray()
            • Rebuild the list so it can be sorted by filename, and then sort it.
            • For each entry in the sorted list, $oPairSub = $this->SubPair(DIRECTORY_SEPARATOR.<filename>)
            • Something then has to call Spider->OnPath($oPairSub).
              • I could pass the Spider object in, but again that's adding a dependency.
              • I could return a final array of Pair objects, which would mean we'd have to iterate through it a third time.
      • Maybe the obvious solution is best, here?
        • ...except it has the same objection as #3: something has to call Spider->OnPath($oPairSub).
        • ...and it would need to receive a copy of the current Pair object, as well, in order to create the sub-Pair.
        • Maybe what simplifies the matter is if we make a callback-interface for each sorted file, so the dependency isn't on Spider but on a much more general thing.
          • Possibly it could be an Event, OnFile (which happens to be what the function in Spider is called).
          • If I refactor Spider to use the Event interface, that should fit the bill. Then FileSys just needs to define two additional Event-types: OnFile and OnFolder.
  • 14:35 New convention: Event-type clade names should be prefixed with "On".
  • 20:27 In order to produce the hierarchical progress stats, I need to be able to go back up the chain and each link needs to have $total and $current values...