Re: Coercions
On Fri, Jun 18, 2010 at 09:41:40PM +0100, Pedro Melo wrote:
> Hi,
>
> On Fri, Jun 18, 2010 at 8:35 PM, Jesse Luehrs wrote:
> > On Fri, Jun 18, 2010 at 08:14:28PM +0100, Pedro Melo wrote:
> >> On Fri, Jun 18, 2010 at 7:44 PM, Evan Carroll wrote:
> >> > Actually you can do this with MX::Types too:
> >> >
> >> > use MooseX::Types -declare => [qw( MyDate DateTime )];
> >> > use MooseX::Types::Moose qw( Str Int HashRef Object );
> >> > use DateTime;
> >> >
> >> > class_type DateTime, { class => 'DateTime' };
> >> >
> >> > subtype MyDate, as DateTime, where { ! $_->hour };
> >>
> >> hmms... I had code like that in a previous version but could not get
> >> it to work. The difference is that you added ", where { ! $_->hour }"
> >> and I had only "subtype MyDate, as DateTime;".
> >>
> >> In fact if I remove the "where..." from you working example, the tests
> >> start failing like mine did. I would like to understand why it needs
> >> the where to work. Back to the docs for me.
> >
> > Coercions aren't run if the input value is already of the correct type.
>
> I though of that and thats why my original code used MyDate as a
> subtype of Object, not DateTime. In that case it should run, correct?
No, a DateTime object will pass the Object type constraint.
-doy
Re: Coercions
Hi,
On Fri, Jun 18, 2010 at 8:35 PM, Jesse Luehrs wrote:
> On Fri, Jun 18, 2010 at 08:14:28PM +0100, Pedro Melo wrote:
>> On Fri, Jun 18, 2010 at 7:44 PM, Evan Carroll wrote:
>> > Actually you can do this with MX::Types too:
>> >
>> > use MooseX::Types -declare => [qw( MyDate DateTime )];
>> > use MooseX::Types::Moose qw( Str Int HashRef Object );
>> > use DateTime;
>> >
>> > class_type DateTime, { class => 'DateTime' };
>> >
>> > subtype MyDate, as DateTime, where { ! $_->hour };
>>
>> hmms... I had code like that in a previous version but could not get
>> it to work. The difference is that you added ", where { ! $_->hour }"
>> and I had only "subtype MyDate, as DateTime;".
>>
>> In fact if I remove the "where..." from you working example, the tests
>> start failing like mine did. I would like to understand why it needs
>> the where to work. Back to the docs for me.
>
> Coercions aren't run if the input value is already of the correct type.
I though of that and thats why my original code used MyDate as a
subtype of Object, not DateTime. In that case it should run, correct?
Bye,
--
Pedro Melo
http://www.simplicidade.org/
xmpp:m...@simplicidade.org
mailto:m...@simplicidade.org
Re: Coercions
> Coercions aren't run if the input value is already of the correct type. Since .72 -- Evan Carroll System Lord of the Internets
Re: Coercions
On Fri, Jun 18, 2010 at 08:14:28PM +0100, Pedro Melo wrote:
> Hi,
>
>
> On Fri, Jun 18, 2010 at 7:44 PM, Evan Carroll wrote:
> > Actually you can do this with MX::Types too:
> >
> > use MooseX::Types -declare => [qw( MyDate DateTime )];
> > use MooseX::Types::Moose qw( Str Int HashRef Object );
> > use DateTime;
> >
> > class_type DateTime, { class => 'DateTime' };
> >
> > subtype MyDate, as DateTime, where { ! $_->hour };
>
> hmms... I had code like that in a previous version but could not get
> it to work. The difference is that you added ", where { ! $_->hour }"
> and I had only "subtype MyDate, as DateTime;".
>
> In fact if I remove the "where..." from you working example, the tests
> start failing like mine did. I would like to understand why it needs
> the where to work. Back to the docs for me.
Coercions aren't run if the input value is already of the correct type.
-doy
Re: Coercions
Hi,
On Fri, Jun 18, 2010 at 7:44 PM, Evan Carroll wrote:
> Actually you can do this with MX::Types too:
>
> use MooseX::Types -declare => [qw( MyDate DateTime )];
> use MooseX::Types::Moose qw( Str Int HashRef Object );
> use DateTime;
>
> class_type DateTime, { class => 'DateTime' };
>
> subtype MyDate, as DateTime, where { ! $_->hour };
hmms... I had code like that in a previous version but could not get
it to work. The difference is that you added ", where { ! $_->hour }"
and I had only "subtype MyDate, as DateTime;".
In fact if I remove the "where..." from you working example, the tests
start failing like mine did. I would like to understand why it needs
the where to work. Back to the docs for me.
Thank you for the working example, fixed my project.
Bye,
--
Pedro Melo
http://www.simplicidade.org/
xmpp:m...@simplicidade.org
mailto:m...@simplicidade.org
Re: Coercions
For reference, I put a working example up at http://gist.github.com/443985/912c7376cf56d8f1b7fe1b6b5294ea5eef7f06c6 -- Evan Carroll System Lord of the Internets
Re: Coercions
Actually you can do this with MX::Types too:
use MooseX::Types -declare => [qw( MyDate DateTime )];
use MooseX::Types::Moose qw( Str Int HashRef Object );
use DateTime;
class_type DateTime, { class => 'DateTime' };
subtype MyDate, as DateTime, where { ! $_->hour };
Or, whatever makes your subtype special from a regular DateTime that
has hours/min/seconds, etc. I'd probably leave it and just truncate
later though. DateTime is known to have some issues when it acts like
a plain Date module.
--
Evan Carroll
System Lord of the Internets
Re: Coercions
I see those tests are a waste. The deal is this then: subtype MyDate, as Object; What you need to do is subclass DateTime, and make subtype MyDate require that type, then coerce from type DateTime. -- Evan Carroll System Lord of the Internets
Re: Coercions
Hi, On Fri, Jun 18, 2010 at 7:21 PM, Evan Carroll wrote: >> I'm trying to create a Date type, and one of the coercions I wanted >> was from a DateTime object. I can't get it to work. > > I believe your problem is UTC vs floating. ->from_epoch asserts the > time_zone is UTC unless provided. All other calls to new are > implicitly floating time_zones. No. The coercion from DateTime is not even called. If you look at the output, each coercion prints a line to make sure its is called. There is no such line for the DateTime test. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org
Re: Coercions
> I'm trying to create a Date type, and one of the coercions I wanted > was from a DateTime object. I can't get it to work. I believe your problem is UTC vs floating. ->from_epoch asserts the time_zone is UTC unless provided. All other calls to new are implicitly floating time_zones. -- Evan Carroll System Lord of the Internets http://www.evancarroll.com
Re: Coercions and custom type parameters
- Original Message -
From: Yuval Kogman <[EMAIL PROTECTED]>
Sent: Thu, 24 Jul 2008 23:27:11 +0300
Re: Re: Coercions and custom type parameters
Declaring an attribute with a parameterized type:
has foo => (
isa => "ArrayRef[Foo]",
coerce => 1,
);
has a specific behavior right now, it enables only the coercions on
the type "ArrayRef[Foo]".
OK, I hadn't thought about it that way. So, I can declare a subtype
that looks parametrized, but it really isn't.
subtype 'ArrayRef[Int]' => as 'Str' => where { 1 };
Custom parametrized types could still make sense though:
MyCustomType[Foo]
is a useful construct for custom container types, for functors, etc
etc, so deep_coerce *is* a useful property to have
Wow, I didn't know that was possible either. You guys have thought of
everything...
So, this is my custom collection, which is parameterizable:
subtype 'BigArrayRef' => as 'ArrayRef' => where { scalar(@$_) > 1 };
has 'my_big_arrayref' => ( is => 'rw', isa => 'BigArrayRef[Int]' );
Now, I can also create a pseudo parameterizable subtype, that does
something like this:
subtype 'BigArrayRef[Int] => as 'ArrayRef' => where {
my $ar = $_;
return unless scalar( @$ar ) > 1;
for ( @$ar ) {
return unless m/^ \d+ $/x;
}
return 1;
}
Well what does this mean now:
has 'my_new_big_arrayref' => ( is => 'rw', isa => 'BigArrayRef[Int][Int]' );
I think I've just confused myself. I'm going to sit down and play
with this some more...
Thanks,
Charles Alderman
Re: Coercions and custom type parameters
On Thu, Jul 24, 2008 at 16:16:28 -0400, Charles Alderman wrote: > I guess that if you're trying to prevent this as an action at a distance, > 'deep_coerce' wouldn't really be acceptable either. Wouldn't that just be > a more explicit warning of an action at a distance? Declaring an attribute with a parameterized type: has foo => ( isa => "ArrayRef[Foo]", coerce => 1, ); has a specific behavior right now, it enables only the coercions on the type "ArrayRef[Foo]". If this started coercing using 'Foo's coercions we break compatibility, and deining a coercion on 'Foo' affects types that parametrize on it. deep_coerce is different because: a. it doesn't break existing code b. it's explicit about the fact that it's accepting coercions from the type parameter, so a developer would know to look there, instead of looking for coercions on 'ArrayRef[Foo]'. > If moose type constraints become too complicated, I guess at some point, a > designer/developer just needs to turn the parametrized type into its own > class. So, maybe I'm answering my own question here. Custom parametrized types could still make sense though: MyCustomType[Foo] is a useful construct for custom container types, for functors, etc etc, so deep_coerce *is* a useful property to have > At any rate, I'll look more at the mailing list archives... I think this was only discussed on IRC actually -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418
Re: Coercions and custom type parameters
I guess that if you're trying to prevent this as an action at a
distance, 'deep_coerce' wouldn't really be acceptable either.
Wouldn't that just be a more explicit warning of an action at a
distance?
If moose type constraints become too complicated, I guess at some
point, a designer/developer just needs to turn the parametrized type
into its own class. So, maybe I'm answering my own question here.
At any rate, I'll look more at the mailing list archives...
Thanks,
Charles Alderman
- Original Message -
From: Yuval Kogman <[EMAIL PROTECTED]>
Sent: Thu, 24 Jul 2008 22:37:45 +0300
Re: Re: Coercions and custom type parameters
This has been brought up before, the short story is 'coerce => 1'
may introduce action at a distance, so we decided that if at all
this should be 'deep_coerce => 1'.
At any rate, this is a little trickier than it sounds, but if Stevan
approves deep_coerce => 1 feel free to commit this as a todo test
and start hacking away.
Regards,
Yuval
On Thu, Jul 24, 2008 at 15:20:13 -0400, Charles Alderman wrote:
Hello Moose,
I guess I have an enhancement idea/request.
I have a parametrized ArrayRef[] of a custom type, I'd like my coercion on
that type to work for any of the values in the collection. HashRef[]s
should work too. Maybe Maybe[]s, but not in my example below.
Would this be worthwhile or viable? If so, I'd be willing to attempt a
patch...
Thanks,
Charles Alderman
Here's a test:
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests => 2;
use Test::Exception;
{
package Foo;
use Moose;
use Moose::Util::TypeConstraints;
enum 'Foo::Values' => qw{ Foo Bar Baz None };
coerce 'Foo::Values' => from 'Undef' => via { 'None' };
has 'array_of_foo' => (
is => 'rw',
isa=> 'ArrayRef[Foo::Values]',
coerce => 1,
);
}
{
my $foo = Foo->new();
my @ok_values = ( 'Foo', 'Bar', 'Baz', 'None' );
my @coerced_values = ( 'Foo', 'Bar', undef, 'None' );
lives_ok {
$foo->array_of_foo( [EMAIL PROTECTED] );
}
'... setting array with ok values';
lives_ok {
$foo->array_of_foo( [EMAIL PROTECTED] );
}
'... setting array with coerced values';
}
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
Re: Coercions and custom type parameters
This has been brought up before, the short story is 'coerce => 1'
may introduce action at a distance, so we decided that if at all
this should be 'deep_coerce => 1'.
At any rate, this is a little trickier than it sounds, but if Stevan
approves deep_coerce => 1 feel free to commit this as a todo test
and start hacking away.
Regards,
Yuval
On Thu, Jul 24, 2008 at 15:20:13 -0400, Charles Alderman wrote:
> Hello Moose,
>
> I guess I have an enhancement idea/request.
>
> I have a parametrized ArrayRef[] of a custom type, I'd like my coercion on
> that type to work for any of the values in the collection. HashRef[]s
> should work too. Maybe Maybe[]s, but not in my example below.
>
> Would this be worthwhile or viable? If so, I'd be willing to attempt a
> patch...
>
> Thanks,
> Charles Alderman
>
>
> Here's a test:
>
>
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use Test::More tests => 2;
> use Test::Exception;
>
> {
>
> package Foo;
> use Moose;
> use Moose::Util::TypeConstraints;
>
> enum 'Foo::Values' => qw{ Foo Bar Baz None };
> coerce 'Foo::Values' => from 'Undef' => via { 'None' };
>
> has 'array_of_foo' => (
> is => 'rw',
> isa=> 'ArrayRef[Foo::Values]',
> coerce => 1,
> );
>
> }
>
> {
> my $foo = Foo->new();
>
> my @ok_values = ( 'Foo', 'Bar', 'Baz', 'None' );
> my @coerced_values = ( 'Foo', 'Bar', undef, 'None' );
>
> lives_ok {
> $foo->array_of_foo( [EMAIL PROTECTED] );
> }
> '... setting array with ok values';
>
> lives_ok {
> $foo->array_of_foo( [EMAIL PROTECTED] );
> }
> '... setting array with coerced values';
>
> }
>
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpV6YwMidKyV.pgp
Description: PGP signature
