Skip to content

Prototype Delegation Chain

Runtime delegation model — instantiates Controlled Inheritance Propagation

An object inherits from another live object by delegation: a property miss falls through the chain of prototypes until it resolves, and a local property simply shadows the inherited one.

A Prototype Delegation Chain makes an object inherit behavior not from a class but from another object — its prototype — which delegates in turn to its own prototype, forming a live chain. When a property or method is requested and the object lacks it, the lookup falls through link by link up the chain until it hits or the chain ends. Its distinctive move among the siblings is that inheritance here is a runtime lookup along a mutable chain of live objects, not a fixed compile-time hierarchy: mutate a prototype and every delegate sees the change at once, and a local property overrides an inherited one merely by being found first. Where the class-based sibling freezes structure at definition time, this one keeps the lineage as live, walkable data.

Example

In a browser game, every on-screen enemy delegates to a shared enemyProto object that holds speed, takeDamage(), and render(). A fastEnemy sets its own speed — shadowing the prototype's — but inherits takeDamage and render by delegation, copying nothing. enemyProto itself delegates to a base entityProto carrying position and update(). So a request for boss.render walks boss → enemyProto → entityProto until render is found.

Mid-game, buffing every enemy is a one-line change to enemyProto.speed: each enemy that has not set its own speed instantly moves faster, because it holds a live link to the prototype, not a copy. That reach is the point — and the hazard. The effective value of any property is whatever the walk resolves to first, so when a designer later adds a fourth link to the chain, every property miss becomes a four-hop search, and the team keeps hot-path objects shallow precisely because depth taxes every lookup. This is the same delegation model that Self and JavaScript are built on.

How it works

  • Link, don't copy. Each object holds a reference to its prototype; shared state lives once, upstream, and is reached by reference.
  • Resolve by fall-through. A property miss delegates up the chain until a hit or the end; the first hit wins, so a local property shadows an inherited one automatically.
  • Stay live. Because links are references to mutable objects, an upstream change is seen immediately by every delegate.
  • Bound the walk. Cap or flatten chains that grow too deep, since every miss pays the full traversal cost.

Tuning parameters

  • Chain depth — how many links delegation runs through. Deeper chains factor more sharing but slow every lookup miss and make effective behavior harder to predict; a depth limit trades reuse for speed and legibility.
  • Shadowing policy — whether a local property may freely override an inherited one or only in declared slots. Free shadowing is flexible but makes accidental masking easy.
  • Mutation discipline — whether prototypes are frozen after setup or hot-patched at runtime. Live mutation is powerful for broad changes but broadcasts surprises to every delegate at once.
  • Flattening cadence — whether to periodically collapse a hot object's resolved state into itself to skip the walk, trading memory and live linkage for lookup speed.

When it helps, and when it misleads

Its strength is near-zero-cost sharing plus instant broadcast: a change upstream reaches every delegate through the live link, and a per-object exception is as cheap as setting one local property. This is the reach that makes prototypal delegation[1] expressive.

The same liveness is the failure mode. Mutating a prototype silently changes distant objects nobody was watching — the invisible propagation the archetype exists to tame — and a deep chain turns a simple property read into an opaque multi-hop search whose effective result is hard to predict. The classic misuse is deepening the chain to reuse "just one more" method until the hierarchy is an unreadable delegation tower. The discipline that guards against it is to keep chains shallow, prefer composition for incidental sharing, and resolve the effective state explicitly when debugging rather than reasoning hop by hop.

How it implements the components

  • lineage_model — the chain of prototype references is the lineage, made an explicit, walkable structure of live objects.
  • default_propagation_rule — an upstream property is the default for every delegate until one shadows it, and changes flow down the live links by default.
  • inheritance_depth_limit — the cap on chain length that keeps lookup cost and predictability bounded.
  • effective_state_view — resolving the walk to the value that actually wins is the effective-state read this mechanism performs on every access.

It does not declare which properties may be overridden (override_scope_declaration — that's Template Clause Override Register), check that a delegate honors an ancestor's contract (substitutability_check — Object-Oriented Class Inheritance), or register inherited risk (inherited_risk_register — Permission Inheritance with Explicit Denial).

Notes

The contrast with class inheritance is the whole point of keeping the two distinct: there are no classes here, the chain is data that can be rewired at runtime, and the effective state is computed per access rather than fixed at definition. That is what makes delegation reach further — and what makes its propagation harder to see.

References

[1] In prototype-based languages such as Self and JavaScript, objects inherit directly from other objects by delegation — an unfound property is looked up on the prototype at runtime — rather than from classes fixed at compile time. The chain is mutable data, which is the source of both its reach and its risk. ↩