While setting up a mapping transform, I realized a boolean expression does not map to values of 0 or 1, but actually requires a false/true map. Automatic equating 0=false and 1=true could be a nice quality of life improvement for folks who tend to think primarily in numeric terms.
Unfortunately, that request would introduce some dangerous conditions for existing users which would break some existing projects; if we were to make a change like that and a user had implemented a Map transform which contained inputs values of 0 and false, which would we map to? As the transform exists currently, the input/output values are literally a Map (hence the name): we store those values as and then reference them with a key which is the input value.
You could always toInt() in your source expression.
That’s an interesting point, hadn’t thought of that. To play devil’s advocate a bit, I think it’d make sense to apply the first or last matching map in a 0=false scenario. As it stands, the maps already support duplicate entries and does just that:
Edit, worth noting that on OKing and reopening the binding, both entries read 0 and it continues to eval to 456
Part of my point was that there is no “safe” way to loop back over a map, and this undermines the efficiency of such a transform. The common “safe” approach is something like this:
my_map.get(desired_key, fallback_value)
where there is one attempt to access, and in the event no such key is found we fall back to using a provided value. Very efficient, very safe, no-nonsense.
To loop back over the map in the event we don’t find the desired_key the first time through means we’d have to have some limit to the number of times we’re willing to loop over the map. How many times are we willing to access the map before we give up and use the default value? Once? Twice? At what point do we give up and use the fallback value?
1 Like
Great explanation! Thanks for taking the time to explain why it’s more troublesome than it appears at first glance
1 Like