Futilities/v0.6/clade/Sys/IO/Store/aux/Spider/Pair

clade: Sys\IO\Store\aux\Spider\Pair

Clade Family StandardBase ⇒ Pair ⇒ (none) Clade Aliases Alias Clade AppAdmin \App Base* [c,i] aux\StandardBase Eventable Sys\Events\aux\Eventable EventOnLoop Sys\Events\Event\Loops\OnLoop EventOnNode Sys\FileSys\Event\OnNode EventOnPath Sys\FileSys\Event\OnPath EventOnMsg Sys\Events\Event\Loops\OnMessage FSLink* [c,i] Sys\FileSys\Aspect\Ident\spex\FSLink SelfIface Sys\IO\Store\aux\Spider\Pair Stat* [c,i] Sys\IO\Store\aux\Spider\Stat Stats* [c,i] Sys\IO\Store\aux\Spider\Stats Subpages @code @code/2026/05/22

Pages

• @code

History

date	what
2024-05-01	converted to class-per-file renamed .\cFSNodePair -> .\IO\Store\Node\cPair
2026-05-04	reinstating this as an auxiliary class for Node\Pair to use as an object
2026-05-05	Revision still in process: moved from Store\Node\ to Store\aux\Spider replacing PathPiece* with Ferreteria clades
2026-05-28	Changed to use FSChain instead of FSLink because the latter does not definitionally have the full filespec, and should not be creating Node objects (which, in fact, it will no longer do).
2026-06-16	It seems perhaps past time to do this: changing PSpecIface $OSpec[A/B] ⇒ NodeIface $ONode[A/B], because we need access to the Node objects. However: It turns out not to make sense to do this, because the new paths are calculated at the OPSpec level, so we'd need to create new Node objects each time anyway. ...so I guess I'm just fixing the code so it can do that. ...except we do need the USpec in order to reconstruct the full Node. Does it make sense to just keep track of the USpec, or should I just go ahead and track the Node? ...yeah, so okay, we're going to do this after all: changed it to track the Node, and changed the constructor to a couple of pseudoconstructors.