[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17
Hi Tal,
Â
I thought a little about this, and did some small background checkâ
Â
So, we get back to special characters. As it happens, â!â is a reserved character in YAML, but â$â is not.
Coincidentally? your proposed â!â character denotes a tag in yaml, i.e. a type, so
prop1: !mystring car
would mean that car is of âtypeâ mystring. Now, TOSCA uses explicit types, so we donât need the YAML tags for that.
Btw. !! starts a global yaml global tag while ! starts a local tag.
Then the idea is that maybe we could use it for functions e.g. something like:
Â
prop1: { !func get_property: [ â ] }
Â
that is to use !func for functions and as we go on with TOSCA to use !whatever for other stuff if needed:
Â
Thoughts:
- â!â is already an escape character in YAML so if you want to have a string starting with â!â then you need to quote it anyway
- $ is not a special character in YAML so it would be TOSCA specific if we use it
- We could expand it later for other stuff
- It kind fits with the âtaggingâ concept in general
- Btw â@â is also a reserved keyword in YAML but for âfuture useâ
- Iâd rather have a âexpandableâ TOSCA tag character then e.g. to reserve $ for functions
Â
Somebody more versed in YAML should check all the implication with â!â, to be sureâ
Â
BR,
/Calin
Â
Â
From: Tal Liron <tliron@redhat.com>
Date: Tuesday, 1 October 2019 at 15:31
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] Proposal for get_property based on discussion in WG on 2019_09_17Â
A long-standing issue for me:
Â
I would also like to propose a special reserved prefix character for function calls. E.g., "$" or "!". So:
Â
{ !get_property: [ ... ] }
Â
The reason should be obvious: as it stands one needs to know all the existing intrinsic functions in order to read a TOSCA source and be sure where there is a function call or just a value of a data type. This will also greatly assist parsers, as they will be able to generate the right error message if it is clear that a function call is intended and the function doesn't exist, etc.
Â
(Puccini allows users to easily create custom functions, something that should probably not be part of the language standard, but that could be acknowledged as a potential feature in the spec.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]