Skip Menu |

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 66093
Status: rejected
Priority: 0/
Queue: Moose

Owner: Nobody in particular
Requestors: AJKALD [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Subject: Subtle change to constraint checks for Bool would help JSON parsing
Download (untitled) / with headers
text/plain 1.2k
The check for Bool at: ll. 714 of Moose::Util::TypeConstraints could be helpfully altered: 713 subtype 'Bool' => as 'Item' => 714 where { !defined($_) || $_ eq "" || "$_" eq '1' || "$_" eq '0' }; When parsing JSON parsed by the standard JSON module against Moose types, the JSON::PP::Boolean objects evaluate false against this test, due to stringification which produces "true" and "false". They do pass the test if the type is changed to: 713 subtype 'Bool' => as 'Item' => 714 where { !defined($_) || $_ eq '1' || $_ eq '0' || "$_" eq '1'|| "$_" eq '0' || $_ eq "" }; Which adds unstringified tests in there as well. While I am perfectly sure you have good reasons for the choice of quoted "$_", this subtle change would make little things like this much easier. This doesn't mean any specific logic for this one class, and probably solves problems for a number of overloaded objects out there. You might wonder why not just try with a coercion? Well, the stringification, combined with overloaded "eq" produced noisy warnings during the check() which coercion cannot silence. It is perfectly possible to coerce, but there should be no need to, as in every practical sense these objects behave boolishly (if that is a word). If the test is reordered to postpone that test, the
Subject: Re: [ #66093] Subtle change to constraint checks for Bool would help JSON parsing
Date: Wed, 23 Feb 2011 21:35:36 +0200
To: bug-Moose [...]
From: Yuval Kogman <nuffin [...]>
Download (untitled) / with headers
text/plain 427b
They don't behave boolishly if you do: if ( ref $obj->some_flag ) it's a subtle backwords incompatibility to introduce this change, but we've always erred on the the conservative side. I'd much rather see the warnings resolved, and to maybe provide a default coercion from the JSON boolean types, and even a new core type like JsonBool or something that also allows the overloaded objects to accommodate round tripping.
Download (untitled) / with headers
text/plain 792b
I'm inclined to not want this change. None of the rest of the core Moose types do special things to deal with overloading (should the CodeRef type accept objects with '&{}' overloading?), and this is by design. If someone wanted to write a type library of some sort for types that handled overloading properly I wouldn't have a problem with that, but I don't think that this is something that we want to do by default. (From a more practical standpoint, at the moment it is quite reasonable to assume that anything stored in an attribute with a Bool type constraint is not a reference - changing Bool to accept certain kinds of references could break existing code that doesn't know how to deal with references (for instance, a serialization routine that doesn't handle serializing objects).)

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to