Tinderbox v9 Icon

Argument evaluation

Evaluation: does this argument allow evaluation of expressions?

An argument's value can be defined in a few ways:

Note that few operators mandate only use of literal argument values. However, Tinderbox's own documentation does not generally address (degree of) argument evaluation. This can mean that at times a use may need to experiment before applying complex argument values to operators in a working document.

Simple evaluations are generally not problematic and, in most cases, no extra preparations are needed.

Complex expressions can arise, often unintentionally, because operator X's argument needs a value being calculated by process Y elsewhere in the document. Thus, an attribute's value might be a call to a user function. To get the literal value of the argument, Tinderbox must read the argument, finding it is an attribute reference, fetch the attribute's value to find that is a function call, call the function, receive the function output … and hope that result is a suitable literal value.

Another aspect is that the scope and capability of Tinderbox action code has changed significantly over the application's 20+ year lifespan. The range of possible interactions between operators can create scenarios where deeply nested evaluations (i.e., evaluation within evaluation within … etc.) arise, and importantly occurring without the user being aware of that. Insufficiently deep evaluation can occur. If it does this should be reported directly to Tinderbox tech support as it will be unintentional unless the limitation is formally documented. Generally, such limitations are resolved, but if encountering them be aware that any fix will require a new app built/release, so in the short term another approach to the problem is required.

aTbRef will document evaluation limits where known, but as stated this aspect of the action code toolbox's interactions is least understood or documented. Be prepared to do small/limited tests if in doubt.