Would it be cleaner to say arg.respond_to?(:value)? Then if we have future evauable things they would just work. That makes me wonder if it might be nice to have an Evaulable mixin, but I'm not sure what exactly we'd put into it. I am seeing a lot of the same pattern of if arg.start_with?("$.") all over the place, which gets me wondering if there's way to DRY that up.

Minor, but I think it's clearer to describe the name with something like

I have one concern here. I was looking through the list of Intrinsic Functions and there is one called States.Array. This would imply we have a Floe::Workflow::IntrinsicFunctions::States::Array class, and that Array shadowing kind of scares me (regardless of const_get or literal). I'm wondering if instead of a full namespacing, we instead just smash the module/function together so you'd get something more like: Floe::Workflow::IntrinsicFunctions::StatesArray. Similarly, there is a States::Hash class. Thoughts?

Hm we could have States be a class with methods def StringToJson and def Array rather than having classes for each intrinsic function. I like having these separated because if/when we have our own ManageIQ intrinsic functions they will be nicely separated.

maybe? methods named with capitals will surely get confusing. If they are class methods then, technicall :: will call those too, which works, but would still be weird. Reminds me of the Vmdb::BUILD method we have.

I like going the send route, aka: def StringToJson (or def intrinsicStringToJson if we need to start with a lowercase). Alternatively a case statement may not be the most ruby thing, but that tends to be the defacto implementation for this type of construct across all programming languages (both target language and complier/interpreter language).

All intrinsics are in the same namespace: States.*. I think hardcoding this rather than a generic "look for a period" works best, and we can hardcode any additional namespaces in the future. Lets also avoid regular expressions and use indexOf(")") kind of stuff. It is way too hard to deal with properly nesting parens and regular expressions. Though this implementation may be ok for a first pass.