Learning
flusci.org

Core Ideas

Composition Chooses; Chaining Connects

Compare compatible choices, successors and independent work.

Downloads

The workshop selects identity verification, password collection and entry policy together. Those choices form a larger commitment. Within a registration, verification establishes what admission may consume.

These are different relationships:

Relationship Workshop Example Question to Ask
Composition Google identity + no registration password + selected entry rule Are these choices compatible, and what do they jointly promise?
Chaining Submitted assertion → verified subject → admitted registration What must this step establish before the next may act?
Independent follow-up Entry and confirmation after registration Does one really have to wait for the other?

A composition joins owned commitments. A successor is a legitimate continuation. A chain can branch or resume later; it need not be one long fluent call.

Registration and its two follow-ups Verify identity Admit registration Record account EntryConfirmation Session + owed confirmation Check the sessionand entry policy Deliver message↓Confirm contact

Forcing delivery before entry would change the open-entry promise. Leaving delivery unowned would lose a different promise. The structure must express both independence and responsibility.

Engineering Depth

The verification contract connects its result to admission:

pub trait VerifyIdentity: private::Stage + Sized {
    type Registered: RecordedRegistration;
    type Verified: AdmitRegistration<Registered = Self::Registered>;
    fn verify(self) -> Result<Self::Verified, IdentityFailure>;
}

Compare an unrelated result with a constrained successor:

// A result type with no declared next capability:
type Verified;

// A declared successor relationship:
type Verified: AdmitRegistration<Registered = Self::Registered>;

These are alternative associated-type declarations inside a trait. The second lets a generic consumer continue through admission without knowing the private carrier's concrete type. It also keeps the declared registration result connected.

The reference exposes independent follow-ups together:

pub trait RecordedRegistration: private::Stage + Sized {
    type Session;
    type Confirmation;
    fn into_followups(self) -> (Self::Session, Self::Confirmation);
}

A returned confirmation handle is not proof that the message was sent. The workshop retains the obligation separately, so dropping the handle does not erase it.

Your Reflection

An implementation makes enter() available only after deliver(). Under the open-entry policy, what promise changed?

Worked Discussion

Entry now waits for delivery even though only current session validity was required. That is a new dependency, not a cosmetic call-order choice. The correct arrangement can keep delivery independently owned while permitting the eligible visit.

Navigation