On 11/11/2014 01:12 PM, Clint Byrum wrote:
> Excerpts from Alexis Lee's message of 2014-11-10 09:34:13 -0800:
>> Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:
>>> Crazy thought: why not just implement conditionals? We had a
>>> proto-spec for them started at one point...
>>
>> I didn't know that was on the table :)
>>
>> How about we support YAQL expressions? https://github.com/ativelkov/yaql
>> Plus some HOFs (higher-order functions) like cond, map, filter, foldleft
>> etc?
>>
>> Here's first_nonnull:
>>
>>   config:
>>     Fn::Select
>>       - 0
>>       filter:
>>         - yaql: "$.0 != null"
>>         - <item1>
>>         - <itemN>
>>
>> Making the 'yaql' function eponymous means we can easily plug other
>> expression languages in later if we choose.

Adding yaql (or similar, e.g. jsonpointer) seems like it would be a good
idea, and shouldn't add more complexity than it's worth.

> Cool. I think this aligns nicely with my suggestion at the summit that
> we also allow writing functions in javascript. This would allow people
> to write their own first_nonnull/coalesce until we have a chance to add
> it:
> 
>   config:
>     embed:
>       lang: javascript
>       args: - item1
>             - item2
>       code: |
>         for (arg in args) {
>           if (arg !== null) {
>             return arg
>           }
>         }
>         return null;
> 
> I'd really love to have this functionality but I doubt I'll have time to
> spec and land it. Does anybody else think this functionality would be a
> good way to allow template authors flexibility that they desire?

I am strongly against allowing arbitrary Javascript functions for
complexity reasons. It's already difficult enough to get meaningful
errors when you **** up your YAML syntax.

AIUI the functionality many users would look to use Javascript
embed-ability for would be better served either by something like yaql,
or by making vendored HOT functions possible.

Vendored HOT would look something like "X-Vendor::YourNamespace" and
functions could be managed similarly to resource plugins (stevedore).
It's a very rough idea, but I like it much better than adding Javascript.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to