-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Function notation: prefix character #67
Comments
An alternate proposal could be that all functions (both intrinsic and custom) must have a YAML seq for arguments (and the
I am less in favor of this. I don't think there's any ambiguity in the original programmatic definition. |
Also a clarification about escaping the properties:
prop1: $myid # valid as is, no need to escape
prop2: my_value But here we do need to escape: properties:
$$prop1: myid # if we don't escape we will get a "malformed function" syntax error
prop2: my_value |
This has been accepted into the spec. Also implemented in Puccini. |
Actually, one more clarifying question: I assume function names can be namespaced, as in |
I don't assume that, at least not for built-in (including custom built-in) functions. It is something we should discuss for user-defined declared functions (#123). Should the
because it wouldn't break the algorithm and wouldn't complicate escaping. |
TOSCA is currently broken. There is no way to provide a value that happens to look like a function call. For example:
In TOSCA 1.X, that last line will always be evaluated as a function call. It cannot be escaped in any way.
The proposal is to require all function calls (both intrinsic and custom) in TOSCA to begin with an escapable prefix character. This will solve the above bug, and also provide a more consistent parsing algorithm for functions (both for TOSCA processors and for the human eye scanning a TOSCA YAML file).
The proposed prefix character is
$
. It would not cause any problems with YAML parsing, and also it would be familiar to users of bash, Perl, Ruby, and many templating languages.I think a programmatic definition makes the most sense:
(extracted from issue #123)
In TOSCA values, for any map of any nested depth:
$
and with length > 1? If yes:$
? If so, discard the first$
and stop here (escape). If yes:Note that I am here assuming that the argument(s) of a function can be anything: a single string value (like
get_input
), a sequence (like all other intrinsic functions), or anything else (for custom functions). I think this is a good idea, as it allows for cleaner syntax, e.g. functions with single arguments (likeget_input
) but also functions with a map argument (compare to kwargs in Python):{ $get_security_context: { env: staging, role: admin } }
The text was updated successfully, but these errors were encountered: