stringification of true

[rurban]

stringification of true

[kanatohodets]

I just bumped into this today for the same reason: I had a Moose Bool type constraint, which checks for "1" and "0" (https://github.com/moose/Moose/blob/master/lib/Moose/Util/TypeConstraints/Builtins.pm#L44). My API client library did use JSON and all my tests were good. When I started using the library in an environment where Cpanel::JSON::XS was imported, my type constraints started to fail due to the override of JSON::PP::Boolean.

I handled this for the moment with coercion for the Moose attributes, but it was a bit of a surprise to discover this difference.

If you don't have strong opinions on this front, I would propose consistency with other notions of string boolean in JSON libraries, Moose, and boolean.pm: use "1" and "0" as the string representations of Cpanel::JSON::XS::true/Cpanel::JSON::XS::false.

[rurban]

ok, let's do "1" then

[rurban]

I thought it's a superior representation than 1 and it's still true. JSON::XS had a bug in it's overload approach, which I fixed, so I could finally do it.
But I'm open minded about it, and never heard about Moose's Bool constraint.

[sezal]

@kanatohodets, I strongly agree with you. It's very frustrating for those who are trying to jump from JSON::XS. I'd vote for "1", but potentially it can break someones code.

[karenetheridge]

closed in #87

[rurban]

Fixed in Release 3.0236