Consider if we should stringify non-string tokens

[eladb]

Following up on #695 and #712, which converted string attributes from strong-typed tokens to stringified tokens, we should consider what to do with other attribute types.

Namely, there are a few attributes in the CloudFormation spec that return string arrays and there one that returns JSON.

Also, we might want to consider what to do for tokens that represent numbers. There are non at the moment in CloudFormation, but an example would be port number.

[rix0rrr]

I would say, same as for string values: we identify a range of special values in the domain that we use to represent tokens.

For numbers, we have two options:

• Hide information in the unused bits of a NaN. That works in-memory (and is in fact sort-of what this unused space was intended for), but we'll have to take care at the JSII border when serializing them, to make it explicit that it's a NaN-w-extra information and JSII front-end implementors will have to carry these bits around as well. Might not be super portable.

• Shrink the range of the double. We can reserve some bits at the upper or lower ranges of the range to encode token numbers. This is probably more portable than the previous one, but again we have to pay attention in jsii land that (a) all languages use doubles, not floats and (b) the stringification of the double contains enough detail that all bits are preserved and properly deserialized.

[rix0rrr]

For lists, we'll have a special singleton list (["${THISISATOKENLIST}"]). However, the operations on lists are no longer trivial. The built-in operations MUST NOT be used anymore, because they cannot do the right thing in all cases.

Instead, we'll have to have functions which people use to operate on arrays, which either do the actual operation on a literal string list, or return a CloudFormation intrinsic in case of a tokenized list.

• array.push(), array.concat(): prohibited, CloudFormation has no equivalent.
• array.length: prohibited, CloudFormation has no equivalent.
• array[5]: translates to Fn.select().
• array.join(): maps to Fn.join()

We could potentially use ES6 Proxies to make this work transparently in JavaScript land (user cannot tell the difference and don't have to resort to special functions), but we'd have to stop serializing arrays as "just data" in that case and treat them like interfaces into jsii-land (think List<string> instead of string[]).

[rix0rrr]

That reminds me, string.split() must also not be used anymore today, since it cannot work in the face of tokenized strings. It should produce a Fn.split() when encountering a Tokenized string (that you're NOT allowed to take the length of 😝 )