B2.4 · dive 3 — the guards and the lanes
Unrepresentable, ordinary, and cheap.
Three closings. A3 gates what the data model makes unrepresentable rather than merely discouraged; A4 proves archetypes are ordinary rows under the same law as everything else; A5 times the read path across three lanes — and the third lane delivers the chapter's best sentence.
Source: content/bcs2.4.md, quoting bcs_rung_2_4_check.out; the working
chains are depth two, and depth eight is a cap, not a recommendation.
The transcript
bcs_rung_2_4_check.out · verbatim · this dive reads A3, A4, and A5boot: the registry grows by one -- ARC, archetype definitions as rows A1 order ok -- composition order proven: tick 0.25 from the instrument, settlement :daily_mark from the archetype, margin true from the base A2 amplify ok -- one definition edited, a thousand instruments follow: multiplier 100 at next read; an instrument row is 18 words, its composed view 14 A3 guard ok -- the diamond is unrepresentable (one :extends) and the cycle is refused: {:error, :cycle}; depth capped at 8: {:error, :depth} A4 rows ok -- archetypes are rows: an AST name refused with {:error, :namespace}; ARC pages newest-first like any property A5 cost ok -- read-time composition over a depth-2 chain: store-lane 5442 ns/op vs snapshot-lane 1048 ns/op; a bare row get is 2653 ns/op PASS 5/5
A3 — the guards are shape, not lint
content/bcs2.4.md · What · DecisionsA3 gates what the design makes unrepresentable rather than merely discouraged:
:extends is one field, so the diamond cannot be written; a cycle is refused typed
({:error, :cycle}); a chain past eight is refused typed ({:error, :depth}).
The hierarchy disease is prevented at the data model, where prevention is free. One :extends,
by shape: multiple mixins are modeled as chains or as explicit per-property choices, never as multiple
parents.
The walk carries the seen-set and the depth cap; a dangling :extends
surfaces as the fetch's own {:error, :not_found} — the resolver adds no second vocabulary.
Depth eight is a cap, not a recommendation: the working chains are depth two.
A4 — archetypes are ordinary rows
content/bcs2.4.md · WhatA4 closes the loop with Part I: an AST name offered to the archetype store
earns {:error, :namespace}, and ARC pages newest-first like any property —
definitions are gated, paged, and windowed like everything else, which means they are also
versionable like everything else: hold the definitions in Chapter 2.3's forest and every
archetype edit is a kept epoch, the desk's “what did the margin rules say on Tuesday”
answered by a binding.
The forest belongs to The CHAMP Property Database (B2.3); the store discipline — the gate at every ingress, the newest-first paging — to Property Stores on ETS (B2.2).
A5 — three lanes, one punchline
content/bcs2.4.md · What · quoting bcs_rung_2_4_check.outA5 times the read path: store-lane 5442 ns/op vs snapshot-lane 1048 ns/op
for a depth-2 resolve, against a bare row get is 2653 ns/op. The snapshot-lane resolve — the
full composition, pure, over a defs snapshot — is cheaper than a single bare get through the
boundary. Composition was never the cost; the boundary crossing was, and Chapter 2.3's snapshot-out
pattern pays for itself one chapter later.
Snapshot the definitions store the moment resolves outnumber edits — which on a trading platform is immediately — and re-snapshot per epoch, not per read. Resolution is uncached by design at this rung: the epoch-snapshot lane is the cache strategy.
References
sources · relatedSources
- West — Evolve Your Hierarchythe component turn; the hierarchy disease named at industry scale
- Venners — Design Principles from Design PatternsGamma on composition over inheritance, defended a decade on
Related
- B2.4 — Archetypes and Compositionthe module hub; the full rung in context
- B2 — The Elixir BCS Corethe chapter landing; the Part II arc
- B2.2 — Property Stores on ETSthe gate and the paging the A4 rows obey
- B1 — Ideas Behindthe law and the identity contract
- Functional Programming in Elixirthe umbrella where echo_data lives