Skip Menu |
 

This queue is for tickets about the Type-Tiny CPAN distribution.

Report information
The Basics
Id: 86892
Status: resolved
Priority: 0/
Queue: Type-Tiny

People
Owner: perl [...] toby.ink
Requestors: TIMB [...] cpan.org
Cc:
AdminCc:

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



Subject: Reduce boilerplate for message
Download (untitled) / with headers
text/plain 748b
The message example in the docs demonstrates the value of using the "most general" constraint as the message: declare EvenInt, as Int, where { $_ % 2 == 0 }, message { if (Int->check($_)) { "$_ is an integer, but not even" } else { "$_ is not an integer" } }; but that approach rapidly gets unwieldy with deeper hierarchies of types (Int -> Int2 -> Int2_not_negative etc) Firstly, are there any problems with rewriting that as: message { return Int->get_message($_) unless Int->check($_); "$_ is an integer, but not even"; }; which seems much cleaner. And secondly, could Type::Tiny do that for me? Perhaps optionally, but default on as it seems most people would want that.
Download (untitled) / with headers
text/plain 814b
Personally I don't use message much. I'd generally recommend it only for cases where you want to give especially interesting diagnostics for why a value fails a constraint. Otherwise I'd generally suggest using the default message. You may be intersted in perusing Type::Exception::Assertion. When Type::Tiny's assertion functions emit an error message for a failed type constraint, they don't die with a string; they throw an exception object (which overloads stringification). This exception object has an ->explain method that does delve into at what "level" of the type constraint hierarchy the value failed the constraint. (i.e. Does $x fail ArrayRef because it's a reference to a non-array value; because it's not a reference at all; or because it's not even defined?) I'll think some more on this though.
Download (untitled) / with headers
text/plain 235b
Marking this as stalled because I don't have any concrete ideas to improve matters, but also don't see a desperate need for improvement. If anybody has any ideas for making custom messages easier to write, feel free to add them below.
Download (untitled) / with headers
text/plain 274b
Well, firstly, are there any problems with rewriting the example in the docs as: message { return Int->get_message($_) unless Int->check($_); return "$_ is an integer, but not even"; }; which seems much cleaner and demonstrates a useful technique?
Download (untitled) / with headers
text/plain 163b
On 2013-07-18T15:46:56+01:00, TIMB wrote: Show quoted text
> Well, firstly, are there any problems with rewriting the example in > the docs
No, I don't have any problem with that.
Download (untitled) / with headers
text/plain 690b
OK, I've updated the documentation in 0.017_01. I've gone for an even simpler technique: declare EvenInt, as Int, where { $_ % 2 == 0 }, message { Int->validate($_) or "$_ is not divisible by two"; }; This works because Type::Tiny provides a `validate` method (stolen from the Moose API) which returns undef if the value passes the type constraint, and returns the same as `get_message` if it fails. Hopefully this is sufficient boilerplate reduction. Marking as patched, and will mark as resolved once this goes into a stable release. (Though it's just a doc patch, so the technique already works - indeed, probably has since 0.001.) Thanks for all the feedback Tim.
Resolved in 0.018.


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.