Ownership and Lifetimes

Reader Question

Where do live objects belong, and when are they reused or disposed?

Short Answer

Melder assigns every resolved object to an explicit lifetime boundary. The broadest objects belong to a frame; narrower objects belong to conduits, conduit lineages, clusters, or request-local spell spaces; many produces a new object per meld. Cleanup walks owned scopes inward-to-outward and disposes objects in reverse creation order.

Melder ownership and lifetime map

Editable diagram source

Lifetime Choices

Existence	Reuse boundary	Typical role
`unique`	Aetheric frame	Configuration, pools, shared services
`unique_per_conduit`	One conduit	Session or request scope
`unique_per_conduit_lineage`	Root and lesser-conduit family	Context shared down a scope tree
`unique_per_conduit_cluster`	Named conduit group	Coordinated cross-scope service
`unique_per_spell_space`	Active spell space	Request-local ephemeral state
`many`	None	Fresh workers or value-producing services

Cleanup Is Part of the Model

Creation stores preserve registration order for teardown. Newer dependents are disposed before earlier dependencies, and failures are aggregated so one bad disposer does not prevent the remaining scope from being cleaned.

Why This Design Is Strong

Scope is expressed in the same graph that creates objects. The runtime therefore knows which store may reuse an instance and which owner must eventually dispose it.

Tradeoffs

Application authors must choose lifetimes and teardown vocabulary explicitly. That cost buys predictable reuse, deterministic cleanup, and fewer hidden process-wide singletons.

Where to Go Next

Source entry points:

Canonical source · Full contents