OASIS TC Open Repository: Manages TOSCA profiles, tests, and templates that are maintained by the TOSCA community. They are intended to be used as examples to help developers get started with TOSCA and to test compliance of TOSCA implementations with the standard.
In today's ad hoc discussion we came up with the following:
We like the idea of supporting "magic words" generally in TOSCA as a friendly syntactical shortcut
A "magic word" is a string that is not a YAML map key beginning with "$" (unescaped). It is equivalent to a function call with no arguments (or an empty seq).
For strings that are map keys beginning with "$" (unescaped) the same rules apply as we have previously defined them: we require that the map have only one key (the function name), otherwise it would be a syntax error, and that key's value is the argument or seq of arguments.
In the following example $magic is a function with no arguments that returns an integer:
If we want to use a function call with no arguments as YAML keys, we have to use the full syntax instead of magic words. Here $keygen returns a GUID string:
In today's ad hoc discussion we came up with the following:
We like the idea of supporting "magic words" generally in TOSCA as a friendly syntactical shortcut
A "magic word" is a string that is not a YAML map key beginning with "$" (unescaped). It is equivalent to a function call with no arguments (or an empty seq).
For strings that are map keys beginning with "$" (unescaped) the same rules apply as we have previously defined them: we require that the map have only one key (the function name), otherwise it would be a syntax error, and that key's value is the argument or seq of arguments.
In the following example
$magic
is a function with no arguments that returns an integer:If we want to use a function call with no arguments as YAML keys, we have to use the full syntax instead of magic words. Here
$keygen
returns a GUID string:(There is a potential problem in the example above in situations with multiple identical keys in YAML. See issue #134)