pub struct SeqSlot<Entry, ChildEntry> {
pub wrap: fn(ChildEntry) -> Entry,
pub project: fn(&Entry) -> Option<&ChildEntry>,
}Expand description
Where a child’s appended entries live inside its parent’s sequence.
Slot’s counterpart, and the same idea one type along: the parent’s Entry is a sum, the
child’s entries are one of its variants, and both append into one sequence rather than two.
One sequence is what keeps the ordering between a parent’s entry and its child’s real — two
would have no order between them at all, and a recovery replaying them would be inventing one.
wrap puts a child’s entry into the parent’s vocabulary; project takes it back out and says
None for an entry that is not the child’s.
§The positions the child sees are the parent’s
The store handed to such a child filters the parent’s sequence to the child’s variant, so what the child
reads back is its own entries in order — but the Positions are the parent’s, and therefore
sparse: a child’s third entry may sit at position seven. That is deliberate and is all a
cursor needs, since positions are only ever compared and advanced, never counted. A child that
treated a position as an index into its own entries would be wrong, and would have been wrong
about a plain store too.
fn pointers rather than closures, for the reason Slot gives: a slot names a fixed place in
a type, and one that could close over state would name a different place on different calls.
Fields§
§wrap: fn(ChildEntry) -> EntryA child’s entry, in the parent’s vocabulary.
project: fn(&Entry) -> Option<&ChildEntry>The child’s entry inside a parent’s, or None if this entry is not the child’s.