497, in which enum values are changed from an array to an object to allow for additional metadata on each value)
495, in which a <= key shows up on an object in the "requires" array.
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.
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.
I'm thinking about:
497, in which enum values are changed from an array to an object to allow for additional metadata on each value)
495, in which a
<=
key shows up on an object in the"requires"
array.504, in which we had to allow the value of an object in the
"requires"
array to itself be an array."!"
)."requires"
array be sometimes strings and sometimes objects.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 than0
, or any value greater than0
.The main principle here is that an object is going to be more flexible and future-proof than a string.
That's my idea.