> On 20 Dec 2014, at 06:54, Dmitri Zimine <dzim...@stackstorm.com> wrote:
>
> I appended some more ideas on making for-each loop more readable / less
> confusing in the document.
>
> It’s not rocking the boat (yet) - all the key agreements done that far, stay
> so far. It’s refinements.
>
> Please take a look, leave comments, +1 / -1 for various ideas, and leave your
> ideas there, too.
>
> https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit#heading=h.5hjdjqxsgfle
>
> <https://docs.google.com/document/d/1iw0OgQcU0LV_i3Lnbax9NqAJ397zSYA3PMvl6F_uqm0/edit#heading=h.5hjdjqxsgfle>
Dmitri, thanks. Looks like you guys have been really creative around this
blueprint :)
I left my comments in the document. In essence, I would suggest we stop at the
following syntax:
1. Short one-line syntax in case we need to iterate through one array.
task1:
for: my_item in $.my_array
action: my_action ….
2. Full syntax in case there are more than one array that we need to iterate
through.
task1:
for:
my_item1: $.my_array1
my_item2: $.my_array2
...
action: my_action ….
Option 3
task1:
for:
- my_item1 in $.my_array1
- my_item2 in $.my_array2
also looks ok to me but it doesn’t seem a YAML way a little bit because in YAML
we can express key-value pairs naturally like in #2.
Actually, I don’t see any problems with supporting all three options.
As far as naming, let’s comment on each of the options we have now:
‘‘for-each’ - I’d be ok with it but seems like lots of people have been
confused with it so far because their expectation were really different than
the description we told them, so I’m ok to pick a different name.
“map” - I’m totally against it, first glance at “map” would make very little
sense to me even though I understand where this option comes from. I’m pretty
sure it will be even more confusing than “for-each”.
“with_items” - Ansible style, it’s ok to me.
“for” - I think this is my favourite option so far. Semantically it may not be
too different than “for-each” but it’s very concise and most general purpose
languages have the same construct with similar semantics.
After all, my suggestion would be not to spend huge amount of time arguing on
naming. Although it’s pretty important, it’s always subjective to a great
extent.
Thanks
Renat Akhmerov
@ Mirantis Inc.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
