Nit Picking the Factory Design

The factory is introduced here and defined carefully here. Special treatment is given to two of the special components of the factory, the .program and the .keeper. The special treatment is described in detail here and allows the possibility that the component is a factory instead of a sensory key. When the component is a factory then before the confined program begins to run, that component has been replaced by a yield of that factory. I argue here that that special treatment is a bad design.

In order to distinguish the factories under consideration, we call the first factory the PF (prime factory) and one of the possible components of PF we call SF (sub factory).

We must be precise here by what we require of a prompt factory. A factory has processed a request when it has created a new domain, destined to execute the confined program and becomes available for a new request. A factory is prompt if invoking its requestor’s key for a new instance is not indefinitely delayed by a previous such request. Factories are prompt in this sense. The return key to the requestor is delivered to the new domain that normally returns to the requestor after the new object finishes initializing itself. Bugs in the confined code, or unusual designs may mean that the requestor is never returned to.

The first observation is that in order to keep PF prompt, the new domain D is created by PF and D executes code to invoke SF. SF, being an official factory, is guaranteed to quickly accept new creation requests via its requestor’s key, but may not return promptly for that depends on the .program of SF. Thus PF cannot wait on the return from SF to become available for new requests. Deputizing D to invoke SF solves this problem. It also solves the problem of exhaustion of the meter supplied via the requestor’s key to PF.

The code that the newly created domain executes to invoke the factories seems simple enough but recent experience suggests that it should be user replaceable. This has these benefits:

A read-only page holding the code to perform the current logic can be made publicly available. This page can serve as a ready-made ,program for factory builders that need the old functions. For such builders the confined code would be a normal factory component.

This change is slightly incompatible with some current factory building code. It is possible, though unlikely, that some factories would pass the limit of 19 components and thus require the fetcher factory hack.


The recent experience that prompted this idea, is that of the third key argument in the creation order on a factory requestor’s key. That is often a space bank that need not be prompt but may be something else upon agreement of the requestor and the confined code. If one of the special components is a factory key then this agreement must include the confined code of the sub factory. and this may be harder to come by.