mirror of
https://github.com/getgrav/grav.git
synced 2026-03-04 19:41:36 +01:00
08e2bb558a
The function validateNumber only checks for numeric values. **By PHP isNumeric** "42", 1337, 0x539, 02471, 0b10100111001, 1337e0, "not numeric", array(), 9.1 **Will evaluate respectively** '42' is numeric '1337' is numeric '1337' is numeric '1337' is numeric '1337' is numeric '1337' is numeric 'not numeric' is NOT numeric 'Array' is NOT numeric '9.1' is numeric Grav though does not support all value types for a variety of reasons. One being YAML Blueprint definitions, where it makes sense to make a new type value for a more specialized format. Specifically for numbers if a more advance number format it would make sense to make a new type for that number format. YAML spec specifically allows both Integer or Float contexts, as seen in the validate class validateInt and validateFloat. This is useful when the output formats explicitly needs to be a certain format. However, in the case of generic numeric contexts, which numbers could be floats or ints dynamically, the values are cast back to an int currently in Grav numeric validation. Having dynamic primitive number formats is important, true in an interpreted language like JavaScript where 1 and 1.0 will both work for a number value. The reason to cast the type of the variable still is to prevent wide selection of number formats, and to keep Grav in line with primitive YAML field formats.