A couple of comments:
I think I would prefer the use of a reserved character to indicate that a name refers to a function. It keeps things more compact. If we re planning on including a functions block, then it would be desirable to not just declare the functions, but also provide an implementation (e.g. through artifacts).
I remember seeing a proposal from Calin in this area.
I ll put this on the list of topics to discuss during one of our Language Ad-Hoc meetings.
Thanks,
Chris
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Wednesday, March 17, 2021 8:14 AM
To: adam souzis <
adam@souzis.com>
Cc:
tosca@lists.oasis-open.org Subject: Re: [tosca] New syntax for function calls
As a side note -- we've tabled the proposal that TOSCA could be made more extensible than it already is by formally acknowledging that some implementations would add additional "custom" functions.
It's a delicate issue. As Chris pointed out, it would limit portability if users indeed use such functions. On the other hand, ... there's nothing we can do to stop implementations from adding functions, and indeed it seems like a natural
and "correct" way to add various features.
TOSCA already supports metadata everywhere, which allows implementations to ... add any custom data. So, why not acknowledge in the specification that there may be additional functions in some implementations? We can at least provide guidelines
for when new functions should be introduced and encourage more portable solutions.
But we can also go a step further, and perhaps allow these custom functions to be "forward-declared", at least by name, so that other TOSCA processors would at least not consider these functions calls as errors. E.g.:
tosca_definitions_version: tosca_2_0
functions:
- q
- get_output
topology_template:
...
On Wed, Mar 17, 2021 at 9:07 AM adam souzis <
adam@souzis.com > wrote:
Sure, it's just a tosca function that returns its value, so to use your first example:
mynode:
type: MyType
properties:
name: { q: { get_input: site } }
Though of course it much nicer written out like this:
mynode:
type: MyType
properties:
name:
q: { get_input: site }
á
On Wed, Mar 17, 2021 at 7:02 AM Tal Liron <
tliron@redhat.com > wrote:
Right, that proposal was weird for exactly that reason -- treating a name (a non-value) as a value. That's part of the reason I added a second version of that proposal, of using the "aliases" keyword in which actual values are expected.
Can you show us an example from Unfurl of using "q"?
On Wed, Mar 17, 2021 at 7:06 AM adam souzis <
adam@souzis.com > wrote:
Good point, there isn't any ambiguity if there's a leading escape character. I was thing more about your example for node templates, e.g.
"{ concat: [ site-, { get_variable: [ SITE, name ] } ] }"
How do you know it's not a template with that name?
BTW, for the issue you brought up about functions, in Unfurl I have a function called "q" (for "quote") that resolves to its value. That solves the problem in a similar way but doesn't introduce any
new syntax.