Tinderbox v10 Icon

Chaining prototypes

Prototypes may themselves use a prototype, i.e. assign a $Prototype value. This can be useful where several different prototypes share a common base. In such circumstances, it can be useful to use one precursor template and then have several other prototypes using it as their prototype. Changing the upstream prototype will affect all prototypes using it and all notes/agents using the downstream prototype.

An example is swapping in/out a complex Displayed Attributes table, rather than constantly showing/hiding the table. Here, the main prototype has no $DisplayedAttributes value set as does one of the two upstream prototypes. The other upstream prototypes has the desired full Displayed Attributes table set. Toggling the main prototype between using the other two prototypes magically sets/removes the Displayed Attributes table.

Beware the above scales awkwardly if you want to toggle more than one feature separately from others. We might want to alternate between two differing Displayed Attributes tables or none. For that, three upstream prototypes (none, table A, table B). But, it we want to separately control Displayed Attributes and Display Expression, for example, we need four upstream prototype: A & B, A only, B only, neither. For 3 things, it is 3 (ABC on, AB only, AC only, BC only, A only, B only, C only, none). Four discrete aspects? Sixteen upstream prototypes.

So, this is best used to control one or two discrete features. However, if all affected features change together, then only two upstream prototypes could toggle rule/edit/Displayed Attributes/Display Expression/shape/colour/export templates/etc. via one prototype selection switch.

Another instance is where it is desirable for the prototype to tell inheriting notes to observe the disablement state of their prototype's rule, edict or code: recall that being controlled by intrinsic attributes that state is not inherited). For instance, if hundreds of notes re-use a complex rule inherited from their prototype and constant code execution slows the document down. One solution is to use an edict as that runs less frequently. But how to make an on/off switch?

An elegant solution is for the prototype itself to use a pair of upstream prototypes. Thus, one upstream prototype has no rule set, the other one does. By resetting the main prototype's rule to the default, it now inherits its rule for (no rule code or for a rule) from the upstream prototype selected.


See also—notes linking to here: