Skip to main content

MemoryReaderPort

made_core::ports

Trait MemoryReaderPort 

Source 
pub trait MemoryReaderPort: Send + Sync {
    // Required methods
    fn recall<'life0, 'life1, 'async_trait>(
        &'life0 self,
        scope: &'life1 MemoryScope,
    ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait,
             'life1: 'async_trait;
    fn as_known_at<'life0, 'life1, 'async_trait>(
        &'life0 self,
        scope: &'life1 MemoryScope,
        moment: MemoryMoment,
    ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait,
             'life1: 'async_trait;
    fn follow<'life0, 'life1, 'life2, 'life3, 'async_trait>(
        &'life0 self,
        scope: &'life1 MemoryScope,
        from: &'life2 MemoryEntryId,
        to: &'life3 MemoryEntryId,
    ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait,
             'life1: 'async_trait,
             'life2: 'async_trait,
             'life3: 'async_trait;
    fn capabilities(&self) -> MemoryCapabilities;
}
Expand description

Reading what earlier sessions learned, and why.

Three ways of reading, because three different questions get asked: what is known about this at all, what was known at a moment, and how one thing here came from another. The second is not the first filtered by date — it excludes what was learned later about earlier events, which is the whole point of asking it.

Every method here has a consumer: recall is what a session reads when it starts, and the other two are what the conformance suite states as the contract (ADR-013). A method with neither is a shape answering to the backend it was drawn from, which is why the one that had neither is gone.

Required Methods§

Source

fn recall<'life0, 'life1, 'async_trait>( &'life0 self, scope: &'life1 MemoryScope, ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait,

Everything memory holds about scope.

Source

fn as_known_at<'life0, 'life1, 'async_trait>( &'life0 self, scope: &'life1 MemoryScope, moment: MemoryMoment, ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait,

What was known about scope at moment.

Source

fn follow<'life0, 'life1, 'life2, 'life3, 'async_trait>( &'life0 self, scope: &'life1 MemoryScope, from: &'life2 MemoryEntryId, to: &'life3 MemoryEntryId, ) -> Pin<Box<dyn Future<Output = Result<MemoryRecollection, DomainError>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait, 'life3: 'async_trait,

The chain of reasons leading from from back to to.

The question the whole contract exists to answer, and the only one whose failure means the memory has stopped being worth keeping: everything else can be reconstructed by reading, and this cannot.

It answers with the reasons and not with the prose — the edges on the path, in the order they connect. What each end says is what recall is for, and a backend that padded the chain with text would make two contracts out of one.

An empty chain is a real answer: the two are not connected by anything anyone wrote down.

Source

fn capabilities(&self) -> MemoryCapabilities

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§