-
-
Notifications
You must be signed in to change notification settings - Fork 48
Please add ->check_coerce method which returns undef if coercion fails #62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
From [email protected] (@karenetheridge) on 2020-11-26 18:42:18 On 2020-11-26 09:10:22, [email protected] wrote:
FWIW, there is no such interface in Moose::Meta::TypeConstraint, which Type::Tiny emulates (so as to allow for seamless replacement of Moose types with Type::Tiny types in Moose classes). |
From [email protected] on 2020-11-26 19:44:35 Den tors 26 nov. 2020 19:43Karen Etheridge via RT [email protected]
So what? Moose won't use the method so no harm if it exists. Type::Tiny has |
From [email protected] on 2020-11-30 01:03:12 I have thought for a while of adding a default coercion to Maybe[Foo] whenever Foo has a coercion. So then you could do: my $coerced_value_or_undef = Maybe->of(Foo)->coerce($orig_value); |
From [email protected] on 2020-11-30 16:22:53 On 2020-11-30 02:03, Toby Inkster via RT wrote:
I like it, except that if it is to be used more than once that |
From [email protected] on 2020-12-01 17:34:57 Type::Tiny does internally cache the result of $type1->of($type2) to avoid a lot of the internal construction stuff the second time it's called. Of course, sticking it in a state variable and reusing it will be even better. Like the following should output the same refaddr twice: use strict; my $x = Maybe->of( Int ); undef $x; my $y = Maybe->of( Int ); |
From [email protected] on 2020-12-03 09:15:19 Den tis 1 dec. 2020 18:35Toby Inkster via RT [email protected]
OK, good to know. I usually meticulously save my derived types under a new Of course, sticking it in a state variable and reusing it will be even
It also reduces the amount of typing in the long run even if the derived
|
Hmmm, I dunno. package Foo {
use Moo;
use Types::Standard -types;
has n => (
is => 'ro',
isa => Maybe[Int],
coerce => 1,
);
}
say Foo->new( n => 1.1 )->n; Is this not dying counter-intuitive? I'm gonna move this back to an unsure status. |
+1 on this feature. I was going to create this exact issue, with this exact method name, but it's already open. I find myself constantly using checks like |
This should work:
|
Migrated from rt.cpan.org #133814 (status was 'open')
Requestors:
From [email protected] on 2020-11-26 17:10:22
:
The subject pretty much says it all. There is ->coerce which returns the
original value if coercion fails, and ->assert_coerce which dies if
coercion fails but no middle ground which returns false if coercion fails.
It is true that it would just be sugar for Type->check(
Type->coerce($value) ) but it would be very useful sugar, because frankly
those nested calls are ugly, especially when it's inside an if test which
is commonly the case, and even more so in case you use a coercion object:
Coercion->type_constraint(Coercion->coerce($value))! I'm tempted to use try
{ Foo->assert_coerce($value) } but that is really even more ugly, although
less to type.
I can try to make a pull request if it would be welcome.
The text was updated successfully, but these errors were encountered: