Categorical functions became non-strict

[lucaswoj]

From @jfirebaugh on January 26, 2017 23:58

Prior to mapbox/mapbox-gl-function#32, categorical functions were strict about types: a stop such as ["1", 1] would not match a numeric property value 1, and vice versa. But now that stop domain values are used as object keys, everything is coerced to a string, and there's no distinction between strings and numbers.

For comparison, filters are strict about types, and functions should probably be consistent with that.

cc @kronick

Copied from original issue: mapbox/mapbox-gl-style-spec#669

[lucaswoj]

From @jfirebaugh on January 27, 2017 0:0

The current categorical function implementation in gl-native (in mapbox/mapbox-gl-native#7372) is also strict.

[lucaswoj]

From @kronick on January 27, 2017 23:0

@jfirebaugh Ah good catch. Would it be a good solution to use a more purpose-built hash map implementation (i.e. https://www.npmjs.com/package/hashmap) if performance is comparable? That package looks like it will keep type information in tact: https://www.npmjs.com/package/hashmap#no-stringification

If that sounds like a good approach to you, I can try it out.

[lucaswoj]

From @jfirebaugh on January 28, 2017 0:30

That kind of approach was my first thought as well, but I think we can get away with a simpler solution given that all stop domain values are required to be the same type (something which is checked by the validator): record typeof stops[0][0] when we create hashedStops and then check that the input has the same type in evaluateCategoricalFunction.

[lucaswoj]

From @kronick on January 28, 2017 1:11

Ok, so if I understand: categorical functions need to (1) be strict about matching, and (2) the style spec forbids mixed types in a categorical function.

• Where do we enforce (2)? If we enforce it in the style JSON parsing, what should createFunction() do if it gets a stops array with mixed types if/when this module is used elsewhere?
• What should evaluateCategoricalFunction() return if its input is of the wrong type? The default value (currently the value of the first stop, though I believe this is undocumented/undefined behavior)? undefined? Something else?

[lucaswoj]

From @jfirebaugh on January 28, 2017 1:31

(2) is enforced here. It's true that it's possible to use createFunction without running validation first, but I think we're best off making that the responsibility of downstream code and having createFunction assume validity as a precondition. (It already does so in other cases, for example assuming that stops are properly sorted.)

What should evaluateCategoricalFunction() return if its input is of the wrong type?

Returning the value of the first stop is fine for now. I was working on #582 / #480 when I noticed this strictness issue, and my planned solution for #582 / #480 is to add support for a "default" property which can be used in the "wrong type" case as well.