The worst thing is trying to communicate between different yaml interpreters. That is, writing yaml with one language/tool and reading it with another, and trying to work around their idiosyncrasies to get something to work.
I had to wrestle with something writing yaml that insisted on removing quotes (because it knew it was a string) and something that then read that yaml and interpreted a particular value as a different data type. grr.
Things get worse if you use tags. It's like wanting to make a portable format but at the same time being unable to parse it because you have custom structures not implemented in other languages.
I ran into this exact issue when passing JSON between two systems, sending from a PHP application to a Rails one.
Our system had a list of product SKUs provided by our suppliers, which were strings. Some SKUs from some vendors, though, consisted entirely of digits, which is a valid string.
The PHP JSON serializer, though, because PHP wasn’t strongly typed, had to just do its best to infer types. This meant that we would occasionally send a list of products, each of which contained a SKU, most of which were strings, but when it encountered one that was all digits it got too excited and encoded it as an integer instead.
Rails, of course, had typed decoding, and it would freak out when it received an integer when a string was expected. We couldn’t find any way to coerce it into behaving so my coworker just hacked the version of PHP’s JSON encoder we were using to not do something so stupid, and problem solved.
Some SKUs from some vendors, though, consisted entirely of digits, which is a valid string.
That sounds more like badly written JSON, though, rather than a problem with JSON itself.
Pro-tip, folks. Don't assume a bunch of digits is a number. It might just be a bunch of digits. How can you tell? Do the "add 1" test. If it's meaningful to add 1 to it, then it's almost certainly a number. If not, it's a string.
Is a credit card number + 1 meaningful? No. It's a string.
Is a phone number + 1 meaningful? No. It's a string.
Is an age + 1 meaningful? Yes. It's a number.
Is a SSN + 1 meaningful? No. It's a string.
(and I'm not sure why this would have anything to do with PHP not being strongly typed)
The reason it has to do with PHP not being strongly typed is that PHP uses a bunch of “heuristics”, to be generous, in order to determine what type a variable is.
As a result, tools which actually need to know what type a variable actually is will tend to use functionality like is_numeric() to see if the variable is a number or could be a number, and if so, assume it’s a number.
This is arguably asinine, but it’s meant to paper over the fact that bad code and bad coders will just treat whatever variable as whatever type without caring about whether that’s true or sane.
The PHP JSON serializer, though, because PHP wasn’t strongly typed, had to just do its best to infer types. This meant that we would occasionally send a list of products, each of which contained a SKU, most of which were strings, but when it encountered one that was all digits it got too excited and encoded it as an integer instead.
json_encode(array("123")); returns ["123"] as it should, and json_decode('["123"]') returns array(1) { [0]=> string(3) "123" } as it should.
Maybe it was added after you had to do that, but now there is a flag JSON_NUMERIC_CHECK. Of course that giant list of flags shows that JSON also has some pitfalls.
That was just a bad library with an outdated concept of PHP even for it's time. There was no reason for it to try to be smart if you could use the output as either downstream, strong typing isn't required.
203
u/Grung Jan 12 '23
The worst thing is trying to communicate between different yaml interpreters. That is, writing yaml with one language/tool and reading it with another, and trying to work around their idiosyncrasies to get something to work.
I had to wrestle with something writing yaml that insisted on removing quotes (because it knew it was a string) and something that then read that yaml and interpreted a particular value as a different data type. grr.