Support arbitrary expressions on "requires" property

[davidtheclark]

I'm thinking about:

• Document enum values individually #497, in which enum values are changed from an array to an object to allow for additional metadata on each value)
• Add fill-extrude-height, fill-extrude-base, and light root property #495, in which a <= key shows up on an object in the "requires" array.
• Allow one property to require another property to have an array of possible values #504, in which we had to allow the value of an object in the "requires" array to itself be an array.
• The weirdness of having keys in objects represent either a property name or an operator ("!").
• The weirdness of having items in the "requires" array be sometimes strings and sometimes objects.
• The complexity caused by that weirdness in some Studio code I've been looking into.
• Validation should enforce "requires" #499, which is about validating the "requires" values — with validation code that will have to deal with the above.

So I'm wondering if it might be worthwhile to reconsider the current format of the "requires" value, changing it to something that can be more consistent and robust.

How about this: The value of "requires" is always an array of objects, each object with these properties:

• property (required): The required property name.
• operator (optional): An operator pertaining to the property (e.g. "!", "<=").
• values (optional): An array of objects representing satisfactory values for the specified property, each object with these properties:
  • value (required): The satisfactory value.
  • operator (optional): An operator pertaining to the value. For example, maybe you in the future we'll want to specify that some property must have any value other than 0, or any value greater than 0.

The main principle here is that an object is going to be more flexible and future-proof than a string.

That's my idea.

[davidtheclark]

I see one up-thumb ... Anybody else object or agree to this? I can work on a PR if we think it's worth an experiment.

[lucaswoj]

This issue was moved to mapbox/mapbox-gl-js#4130