Bug #76387 for Moose: message for nested subtypes

Sat Apr 07 15:32:57 2012 CHORNY [...] cpan.org - Ticket created

Subject:

message for nested subtypes

Let assume following hierarchy: subtype 'Int', as 'Real', where { int($_) == $_ }, message {"$_ is not integer"}; subtype 'PositiveInt', as 'Int', where { $_ >= 0 }, message {"$_ is not positive"}; in case of positive non-integer 1.5 message still will be "1.5 is not positive". Example of more complex hierarchy is Perl::Dist::WiX::Types, you can see source at http://cpansearch.perl.org/src/CSJEWELL/Perl-Dist-WiX-1.500002/lib/Perl/Dist/WiX/Types.pm There are two possible solutions: 1. Document that message should contain all restrictions. This means that message may be long (7 conditions in case of Perl::Dist::WiX::Types) and it may not be clear which restriction failed. 2. Make Moose output message from restriction that failed ("1.5 is not integer"). -- Alexandr Ciornii, http://chorny.net

Mon Sep 17 05:18:02 2012 obrien.jk [...] gmail.com - Correspondence added

From:

obrien.jk [...] gmail.com

Yes, I like solution 2. As it stands this makes it hard to, e.g. pass on reasons for failure to a user so they can correct input, without having to do an extra layer of screening yourself, which defeats the purpose of using Moose type constraints in the first place. Unless I'm missing an obvious way around that, I think that makes this report of more than wishlist importance. Is there a danger of breaking backwards compatibility by fixing this? i.e. will that stall a fix? J.

Mon Sep 17 05:18:04 2012 The RT System itself - Status changed from 'new' to 'open'

Mon Sep 17 08:27:03 2012 DROLSKY [...] cpan.org - Correspondence added

On Mon Sep 17 05:18:02 2012, jkobrien wrote: Show quoted text

> Yes, I like solution 2. > > As it stands this makes it hard to, e.g. pass on reasons for failure

to Show quoted text

> a user so they can correct input, without having to do an extra layer

of Show quoted text

> screening yourself, which defeats the purpose of using Moose type > constraints in the first place. > > Unless I'm missing an obvious way around that, I think that makes this > report of more than wishlist importance. > > Is there a danger of breaking backwards compatibility by fixing this? > i.e. will that stall a fix?

There's no major back-compat issue, but fixing this is harder than you might think. In many cases, we don't actually ever check the parent constraints, because the child constraint is optimized by including all of its parents' checks in its own optimized version of the check. Doing what you're asking for would require some major changes to how this optimization works.

Mon Sep 17 09:40:55 2012 obrien.jk [...] gmail.com - Correspondence added

From:

obrien.jk [...] gmail.com

Ah, I see. Thanks for the update. In that case, something to that effect in the "Error messages" section of Moose::Util::TypeConstraints POD would be useful. Cheers, J.