Builder registries and content environments

Specialized stores encode intent#

The historical compiler contains numerous named builder arrays for queries, lists, sorting, searching, filtering, layouts, permissions, fields, and serialization behavior. Their existence shows that the architecture did not treat every intermediate result as one undifferentiated object. J02

The contemporary implementation has specialized services and content registries. The useful abstraction is a family of stores with different semantic roles, not a claim that the names of the classes constitute a new memory allocator.

ContentOne#

Builder\ContentOne extends the registry abstraction and disables hierarchical separation for its keys. Its key-modeling method maps a logical name through Placefix::_h. This is a shared output-binding environment whose keys are aligned with the compiler's placeholder convention. J06

“Shared” does not mean every value is immutable or global forever. FileContent::set() writes FILENAME before processing each file. A general implementation must therefore distinguish stable shared values from per-file overlays even when an existing implementation stores both in one object.

ContentMulti#

Builder\ContentMulti uses the separator |. Its key modeling treats the first part as the scope and the second as a placeholder name. A logical access such as view|slot is therefore structurally different from one flat global slot. J06

The dynamic file updater selects files by view and passes that view into file-content processing. The renderer retrieves the corresponding content map. This is direct evidence of context-qualified fan-out from one view's prepared values to several output files. J07

Infusion#

The inspected beginning of Helper\Infusion::buildFileContent() transfers component identifiers, namespace information, author metadata, dates, versions, and other values into Compiler.Builder.Content.One. Some values are copied from existing placeholders; others are transformed from component state or derived from configuration. J06

That distinction matters. A registry transition can be recollection, normalization, derivation, or binding preparation. Calling every transition a “copy” obscures where meaning changes and where context is introduced.

What the source does not prove#

The stores are mutable. Their existence does not prove monotonicity, confluence, complete provenance, or optimal physical memory usage. A rule that overwrites a value can be correct under a phase-ordered policy while falling outside the finite positive closure proof.

The formal framework extracts responsibilities from these stores and then states stronger contracts for portable implementations. It does not claim that the production compiler is secretly executing a lattice calculus merely because the abstraction can be expressed with one.