> 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 OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev