- previously had 'mandatory' (bool) for advanced control of reading
dictionary entries but its meaning was unclear in the calling code
without extra code comments.
Now use IOobjectOption::readOption instead, which allows further
options (ie, NO_READ) and is more transparent as to its purpose in
the code than a true/false bool flag was.
This is a minor breaking change (infrequent, advanced usage only)
- minor code cleanup in dictionary lookup methods
- read construct from dictionary.
Calling syntax similar to dimensionedType, dimensionedSet,...
Replaces the older getEntry(), getOptional() static methods
- support readIfPresent
- literal lookups only for expression strings
- code reduction for setExprFields.
- changed keyword "condition" to "fieldMask" (option -field-mask).
This is a better description of its purpose and avoids possible
naming ambiguities with functionObject triggers (for example)
if we apply similar syntax elsewhere.
BUG: erroneous check in volumeExpr::parseDriver::isResultType()
- not triggered since this method is not used anywhere
(may remove in future version)
- exposed by the new embedded function handling.
Requires local copies of dictionary content instead
(similar to coded BCs handling)
BUG: incorrect formatting for expression function output
ENH: simpler copyDict version taking wordList instead of wordRes
- corresponds to the most common use case at the moment
ENH: expression string writeEntry method
- write as verbatim for better readability
- this revises the changes made in 95cd8ee75c to replace the
SFINAE-type of handling of string hashes with direct definitions.
This places a bit more burden on the developer if creating hashable
classes derived from std::string or variants of Foam::string, but
improves reliability when linking.
STYLE: drop template key defaulting from HashSet
- this was never used and `HashSet<>` is much less transparent
than writing `HashSet<word>` or `wordHashSet`
- follows the principle of least surprise if the expansion behaviour
for #eval and expressions (eg, exprFixedValue) are the same. This
is possible now that we harness the regular stringOps::expand()
within exprString::expand()
- reuse more of stringOps expansions to reduce code and improve the
syntax flexiblity.
We can now embed "pre-calculated" values into an expression.
For example,
angle 35;
valueExpr "vector(${{cos(degToRad($angle))}}, 2, 3)";
and the ${{..}} will be evaluated with the regular string evaluation
and used to build the entire expression for boundary condition
evaluation.
Could also use for fairly wild indirect referencing:
axis1 (1 0 0);
axis2 (0 1 0);
axis3 (0 0 1);
index 100;
expr "$[(vector) axis${{ ($index % 3) +1 }}] / ${{max(1,$index)}}";
