Re: MooseX::Types coercions and $self
- Original Message
From: Evan Carroll m...@evancarroll.com
To: moose@perl.org ML moose@perl.org
Sent: Fri, December 17, 2010 3:00:06 PM
Subject: MooseX::Types coercions and $self
Copied from http://stackoverflow.com/q/4473327/124486
The below is not as well formatted:
Is there anyway to get $self into a MooseX::Types coercion? I have
other data in the object that I want to use to seed my coercion from a
String to an Object. Alternatively, is there anything like
Class::MOP's initializer that will permit me to do this -- it would
have to fire before the type checks.
Requested pseudo code:
with 'DBHandle';
has 'database' = ( isa = 'Str', is = 'ro', default = 'Db' );
has 'schema' = ( isa = 'Str', is = 'ro', default = 'schema' );
has 'table' = ( isa = 'Str', is = 'ro', default = 'column );
has 'columns' = ( isa = DBCols, is = 'ro', default = sub {[qw/foo
bar baz/]} );
Here, I want columns to coerce to a DBCols -- an ArrayRef of DBCol's
(objects) -- requiring the use of catalog, schema, and col attributes
found in the class, and with a dbh/singleton provided by DBHandle.
To make this less-pseudo, the actually situation is only slightly more
complex. I was able to accomplish the above with around, now what I
want I to do is create an attribute trait that would permit this
syntax:
has 'column_id' = (
isa = Int
, is = 'ro'
, traits = ['DBKey']
, default = 5
, column = 'foo'
);
Where the attribute trait column provided by DBKey, coerces to DBCol
the same way that the above columns would: this would require the
ability to access the classes database, schema, table, and again the
singleton for the dbh.
I actually published
http://search.cpan.org/perldoc?MooseX::Types::Parameterizable as an experiment
in starting to provide this capacity. I know someone did some work along these
ways over at http://search.cpan.org/perldoc?MooseX::Types::DBIx::Class building
on top of that. Last time I thought about this issue I also thought an
attribute trait might be the right way to go, but I put it aside a bit to see
what, if anything, was useful with MXT:Parameterizable. Mst told me this was
probably achievable using just MXT:Structured for what that's worth, although I
could just be mis-remembering
john
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
MooseX::Types coercions and $self
Copied from http://stackoverflow.com/q/4473327/124486
The below is not as well formatted:
Is there anyway to get $self into a MooseX::Types coercion? I have
other data in the object that I want to use to seed my coercion from a
String to an Object. Alternatively, is there anything like
Class::MOP's initializer that will permit me to do this -- it would
have to fire before the type checks.
Requested pseudo code:
with 'DBHandle';
has 'database' = ( isa = 'Str', is = 'ro', default = 'Db' );
has 'schema' = ( isa = 'Str', is = 'ro', default = 'schema' );
has 'table' = ( isa = 'Str', is = 'ro', default = 'column );
has 'columns' = ( isa = DBCols, is = 'ro', default = sub {[qw/foo
bar baz/]} );
Here, I want columns to coerce to a DBCols -- an ArrayRef of DBCol's
(objects) -- requiring the use of catalog, schema, and col attributes
found in the class, and with a dbh/singleton provided by DBHandle.
To make this less-pseudo, the actually situation is only slightly more
complex. I was able to accomplish the above with around, now what I
want I to do is create an attribute trait that would permit this
syntax:
has 'column_id' = (
isa = Int
, is = 'ro'
, traits = ['DBKey']
, default = 5
, column = 'foo'
);
Where the attribute trait column provided by DBKey, coerces to DBCol
the same way that the above columns would: this would require the
ability to access the classes database, schema, table, and again the
singleton for the dbh.
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011
1.08..master breaks MooseX::Getopt DWIM coercions
2b54d2a6b7bf40c4408ffbc117f6b6d77ee35c67 by Dave Rolsky broke this
DWIM MX::Getopt program:
package Xailo;
use 5.012;
use Any::Moose;
with any_moose('X::Getopt');
has args = (
documentation = Arguments for the engine class,
isa = 'HashRef',
coerce= 1,
is= ro,
default = sub { +{} },
);
sub run {
my ($self) = @_;
say $_ = $self-{args}{$_} for sort keys %{ $self-{args} };
}
package xailo;
Xailo-new_with_options-run;
Before:
foo = bar
this = that
After:
Attribute (args) does not pass the type constraint because:
Validation failed for 'HashRef' with value foo at
/home/v-perlbrew/perl5/perlbrew/perls/perl-5.13.2/lib/site_perl/5.13.2/x86_64-linux/Moose/Meta/Attribute.pm
line 746
Can this be made to work instead of dying? Perhaps a coercion needs to
be added to MooseX::Getopt?
Re: 1.08..master breaks MooseX::Getopt DWIM coercions
On Sun, 18 Jul 2010, Ævar Arnfjörð Bjarmason wrote:
2b54d2a6b7bf40c4408ffbc117f6b6d77ee35c67 by Dave Rolsky broke this
DWIM MX::Getopt program:
package Xailo;
use 5.012;
use Any::Moose;
with any_moose('X::Getopt');
has args = (
documentation = Arguments for the engine class,
isa = 'HashRef',
coerce= 1,
is= ro,
default = sub { +{} },
);
sub run {
my ($self) = @_;
say $_ = $self-{args}{$_} for sort keys %{ $self-{args} };
}
package xailo;
Xailo-new_with_options-run;
Before:
foo = bar
this = that
After:
Attribute (args) does not pass the type constraint because:
Validation failed for 'HashRef' with value foo at
/home/v-perlbrew/perl5/perlbrew/perls/perl-5.13.2/lib/site_perl/5.13.2/x86_64-linux/Moose/Meta/Attribute.pm
line 746
Can this be made to work instead of dying? Perhaps a coercion needs to
be added to MooseX::Getopt?
Well, it shouldn't die any more, just warn. But it still should be fixed.
I don't understand why you're passing coerce = 1 there. Where is the
coercion defined?
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: 1.08..master breaks MooseX::Getopt DWIM coercions
On Sun, Jul 18, 2010 at 15:11, Dave Rolsky auta...@urth.org wrote:
On Sun, 18 Jul 2010, Ævar Arnfjörð Bjarmason wrote:
2b54d2a6b7bf40c4408ffbc117f6b6d77ee35c67 by Dave Rolsky broke this
DWIM MX::Getopt program:
package Xailo;
use 5.012;
use Any::Moose;
with any_moose('X::Getopt');
has args = (
documentation = Arguments for the engine class,
isa = 'HashRef',
coerce = 1,
is = ro,
default = sub { +{} },
);
sub run {
my ($self) = @_;
say $_ = $self-{args}{$_} for sort keys %{ $self-{args} };
}
package xailo;
Xailo-new_with_options-run;
Before:
foo = bar
this = that
After:
Attribute (args) does not pass the type constraint because:
Validation failed for 'HashRef' with value foo at
/home/v-perlbrew/perl5/perlbrew/perls/perl-5.13.2/lib/site_perl/5.13.2/x86_64-linux/Moose/Meta/Attribute.pm
line 746
Can this be made to work instead of dying? Perhaps a coercion needs to
be added to MooseX::Getopt?
Well, it shouldn't die any more, just warn. But it still should be fixed.
I don't understand why you're passing coerce = 1 there. Where is the
coercion defined?
Indeed it should. When I wrote this I /thought/ that the coerce
argument was what was doing the foo=bar - { foo = bar }
magic. But evidently not, it works just fine without it.
So, false alarm, and this fixes it:
http://github.com/avar/hailo/commit/4dbac78b07a
Re: 1.08..master breaks MooseX::Getopt DWIM coercions
On Jul 18, 2010, at 11:29 AM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Jul 18, 2010 at 15:11, Dave Rolsky auta...@urth.org wrote:
On Sun, 18 Jul 2010, Ævar Arnfjörð Bjarmason wrote:
2b54d2a6b7bf40c4408ffbc117f6b6d77ee35c67 by Dave Rolsky broke this
DWIM MX::Getopt program:
snip
Can this be made to work instead of dying? Perhaps a coercion
needs to
be added to MooseX::Getopt?
Well, it shouldn't die any more, just warn. But it still should be
fixed.
I don't understand why you're passing coerce = 1 there. Where is
the
coercion defined?
Indeed it should. When I wrote this I /thought/ that the coerce
argument was what was doing the foo=bar - { foo = bar }
magic. But evidently not, it works just fine without it.
No, MooseX::Getppt sees the HashRef type and then treats the --args
attribute as key-value pair arguments (see Getopt::Long for details on
this feature). No type coercions are done at all unless you
specifically ask for them.
Just a side note, this would have required we add a coercion on the
core HashRef type, which is considered extremely bad manners since the
core types are shared by all and global and should never have
coercions added to them.
- Stevan
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
Hi, On Fri, Jun 18, 2010 at 7:21 PM, Evan Carroll e...@dealermade.com 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 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
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 e...@dealermade.com 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 8:35 PM, Jesse Luehrs d...@tozt.net 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 e...@dealermade.com 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
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 d...@tozt.net 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 e...@dealermade.com 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
Maybe[Foo] type coercions
I'm having difficulty getting a type coercion to work that involves Maybes.
I've looked at the deep coercion section of Moose::Manual::Types, and I'm
not sure what I'm missing to get this to work?
e.g. I'm running
perl -MData::Dumper -MObject -MDateTime -I. -wle'my
$o=Object-new(date=-00-00 00:00:00); print Dumper($o)'
against this module, Object.pm:
package Object;
use Moose;
use Moose::Util::TypeConstraints;
use DateTime;
use DateTime::Format::MySQL;
has date = ( is = 'rw', isa = 'MaybeDateTime', coerce = 1 );
# this generates Attempt to free unreferenced scalar error!
#has date = ( is = 'rw', isa = 'Undef | DateTime', coerce = 1 );
subtype 'DateTime' = as 'Object' = where { $_-isa('DateTime') };
subtype 'MaybeDateTime'
= as 'Maybe[Object]'
= where { $_-isa('DateTime') or not defined $_ };
coerce 'MaybeDateTime'
= from 'DateTime'
= via { return $_ };
coerce 'MaybeDateTime'
= from 'Str'
= via {
print ### calling Str-MaybeDateTime coercion\n;
# check for retarded mysql 4.x null times
return if $_ eq '-00-00 00:00:00';
return DateTime::Format::MySQL-parse_datetime($_);
};
coerce 'DateTime'
= from 'Str'
= via {
print ### coercing Str $_ into DateTime\n;
return DateTime::Format::MySQL-parse_datetime($_);
};
1;
--
A dozen, a gross, and a score,
plus three times the square root of four,
divided by seven,
plus five times eleven,
equals nine squared and no more!
. ... .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: Maybe[Foo] type coercions
On Mon, Feb 15, 2010 at 04:25:54PM -0800, Karen Etheridge wrote:
I'm having difficulty getting a type coercion to work that involves Maybes.
I've looked at the deep coercion section of Moose::Manual::Types, and I'm
not sure what I'm missing to get this to work?
e.g. I'm running
perl -MData::Dumper -MObject -MDateTime -I. -wle'my
$o=Object-new(date=-00-00 00:00:00); print Dumper($o)'
against this module, Object.pm:
package Object;
use Moose;
use Moose::Util::TypeConstraints;
use DateTime;
use DateTime::Format::MySQL;
has date = ( is = 'rw', isa = 'MaybeDateTime', coerce = 1 );
I'm not sure what problem you're having, since you didn't post the
error message, but you probably need the attribute definition to happen
after the types are defined... pretty sure this would assume you have a
class named 'MaybeDateTime'.
# this generates Attempt to free unreferenced scalar error!
#has date = ( is = 'rw', isa = 'Undef | DateTime', coerce = 1 );
If you could turn this issue into an actual failing test, that would be
really helpful.
subtype 'DateTime' = as 'Object' = where { $_-isa('DateTime') };
Also, this is equivalent to class_type 'DateTime'.
subtype 'MaybeDateTime'
= as 'Maybe[Object]'
= where { $_-isa('DateTime') or not defined $_ };
coerce 'MaybeDateTime'
= from 'DateTime'
= via { return $_ };
coerce 'MaybeDateTime'
= from 'Str'
= via {
print ### calling Str-MaybeDateTime coercion\n;
# check for retarded mysql 4.x null times
return if $_ eq '-00-00 00:00:00';
return DateTime::Format::MySQL-parse_datetime($_);
};
coerce 'DateTime'
= from 'Str'
= via {
print ### coercing Str $_ into DateTime\n;
return DateTime::Format::MySQL-parse_datetime($_);
};
1;
-doy
Re: Maybe[Foo] type coercions
On Mon, Feb 15, 2010 at 06:31:24PM -0600, Jesse Luehrs wrote:
On Mon, Feb 15, 2010 at 04:25:54PM -0800, Karen Etheridge wrote:
I'm not sure what problem you're having, since you didn't post the
error message,
Oops sorry, it was:
Attribute (date) does not pass the type constraint because: Validation
failed for 'MaybeDateTime' failed with value -00-00 00:00:00 (not isa
MaybeDateTime) at ...
but you probably need the attribute definition to happen
after the types are defined... pretty sure this would assume you have a
class named 'MaybeDateTime'.
Doh, of course! After moving the 'has' line to the end of the module, now I
get:
Can't call method isa on an undefined value at Object.pm line 15.
...where line 15 is the where line of the subtype 'MaybeDateTime'
definition. However, I see that I'm dereferencing $_ before checking its
definedness, so if I switch to:
= where { not defined $_ or $_-isa('DateTime') };
...then the object constructs properly! Hurrah!
(I suspect that perhaps some of the coercions I have created are
unnecessary; I'll look into that next to see if I can remove them.)
doy++ :)
--
Whoever acquires knowledge but does not practice
it is as one who ploughs but does not sow. - Sa'di
. ... .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
Re: Maybe[Foo] type coercions
Here is slightly less verbose version
package Obj;
use Moose;
use Moose::Util::TypeConstraints;
use DateTime;
use DateTime::Format::MySQL;
class_type 'DateTime';
subtype 'MaybeDateTime' = as 'Maybe[DateTime]';
coerce 'MaybeDateTime'
= from 'Str'
= via {
# check for retarded mysql 4.x null times
return if $_ eq '-00-00 00:00:00';
return DateTime::Format::MySQL-parse_datetime($_);
};
coerce 'DateTime'
= from 'Str'
= via {
return DateTime::Format::MySQL-parse_datetime($_)
};
has 'date' = ( isa = 'MaybeDateTime', is = 'rw', coerce = 1 );
package main;
my $a = Obj-new(date = DateTime-new(year = 2000)); # DT
my $b = Obj-new(date = '-00-00 00:00:00'); # undef
my $c = Obj-new(date = '2000-10-10 00:00:00'); # DT
On Tue, Feb 16, 2010 at 5:25 AM, Karen Etheridge p...@froods.org wrote:
I'm having difficulty getting a type coercion to work that involves Maybes.
I've looked at the deep coercion section of Moose::Manual::Types, and I'm
not sure what I'm missing to get this to work?
e.g. I'm running
perl -MData::Dumper -MObject -MDateTime -I. -wle'my
$o=Object-new(date=-00-00 00:00:00); print Dumper($o)'
against this module, Object.pm:
package Object;
use Moose;
use Moose::Util::TypeConstraints;
use DateTime;
use DateTime::Format::MySQL;
has date = ( is = 'rw', isa = 'MaybeDateTime', coerce = 1 );
# this generates Attempt to free unreferenced scalar error!
#has date = ( is = 'rw', isa = 'Undef | DateTime', coerce = 1 );
subtype 'DateTime' = as 'Object' = where { $_-isa('DateTime') };
subtype 'MaybeDateTime'
= as 'Maybe[Object]'
= where { $_-isa('DateTime') or not defined $_ };
coerce 'MaybeDateTime'
= from 'DateTime'
= via { return $_ };
coerce 'MaybeDateTime'
= from 'Str'
= via {
print ### calling Str-MaybeDateTime coercion\n;
# check for retarded mysql 4.x null times
return if $_ eq '-00-00 00:00:00';
return DateTime::Format::MySQL-parse_datetime($_);
};
coerce 'DateTime'
= from 'Str'
= via {
print ### coercing Str $_ into DateTime\n;
return DateTime::Format::MySQL-parse_datetime($_);
};
1;
--
A dozen, a gross, and a score,
plus three times the square root of four,
divided by seven,
plus five times eleven,
equals nine squared and no more!
. . . . .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI e++ h(-)
--
Regards,
Mikhail
Re: Multiple coercions ?
On Wed, 24 Sep 2008, Alexis Sukrieh wrote: Charles Alderman a écrit : This works for me: [...] I've just ran your test-script, and I got the same error. This is an Ubuntu 8.04 system, the Moose that comes with is 0.31, maybe this is a bug of that version? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
Meta questions: Is the purpose of this list to only report bugs or discuss design questions? Or is it to help out Moose users? Should the list be split into moose-dev and moose-users? Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. Thanks, Charles Alderman - Original Message - From: Dave Rolsky [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 10:14:49 -0500 (CDT) Re: Re: Multiple coercions ? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
Charles Alderman a écrit : Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. It's really funny how you can be flagged newbie at the first mistake you make. Indeed, I totally forgot that Moose grows so quickly that my fresh _stable_ Ubuntu system would be far too old for a bug-proof version of Moose. Indeed, this is my fault. I apology for that. But please don't start to judge people with the first email/mistake you see from them. You don't want to do that. Alexis.
Re: Multiple coercions ?
--- On Wed, 9/24/08, John Napiorkowski [EMAIL PROTECTED] wrote: From: John Napiorkowski [EMAIL PROTECTED] Subject: Re: Multiple coercions ? To: Charles Alderman [EMAIL PROTECTED] Date: Wednesday, September 24, 2008, 12:00 PM --- On Wed, 9/24/08, Charles Alderman [EMAIL PROTECTED] wrote: From: Charles Alderman [EMAIL PROTECTED] Subject: Re: Multiple coercions ? To: moose@perl.org Date: Wednesday, September 24, 2008, 11:34 AM Meta questions: Is the purpose of this list to only report bugs or discuss design questions? Or is it to help out Moose users? Should the list be split into moose-dev and moose-users? Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. Thanks, Charles Alderman Right now we have IRC channels split this way. To be honest, the IRC gets a lot more traffic than the mailing list in terms of discussion and help. This makes sense to me since Moose is rapidly growing and also I've noticed that for Perl there have been a preference to IRC over mailing lists and other types of dicussion (blogging, etc). There is a good part to this, since IRC is immediate, but of course there is a downside since IRC is very unstructured and it's not searched by the big search engines, which I think hurts us PR wise. Try irc://irc.perl.org#moose for general moose questions and irc://irc.perl.org#moose-dev for moose new development. Peace John Napiorkowski - Original Message - From: Dave Rolsky [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 10:14:49 -0500 (CDT) Re: Re: Multiple coercions ? Ok, Moose _0.58_ was just released, and you're reporting bugs in 0.31, which was released approximately 10 months ago? Why? -dave /*== VegGuide.Org Your guide to all that's veg ==*/
Re: Multiple coercions ?
On Wed, Sep 24, 2008 at 11:01 AM, John Napiorkowski [EMAIL PROTECTED]wrote: course there is a downside since IRC is very unstructured and it's not searched by the big search engines, which I think hurts us PR wise. IRC also tends toward a particular culture (if I may dignify it with that term) which I think hurts PR-wise, too.
Re: Multiple coercions ?
I apologize, I don't mean any offense by newbie. It was not my intent to label you that way. I was only referring to the category of questions that are easy to resolve. In regards to Moose, I consider myself a newbie, as opposed to the experts who created it and contribute to it. Thanks, Charles Alderman - Original Message - From: Alexis Sukrieh [EMAIL PROTECTED] Sent: Wed, 24 Sep 2008 17:41:02 +0200 Re: Re: Multiple coercions ? Charles Alderman a écrit : Perhaps if a user happens to overlook the version they're running before asking a question, it could be accepted as a newbie question in a moose-users list conversation. It's really funny how you can be flagged newbie at the first mistake you make. Indeed, I totally forgot that Moose grows so quickly that my fresh _stable_ Ubuntu system would be far too old for a bug-proof version of Moose. Indeed, this is my fault. I apology for that. But please don't start to judge people with the first email/mistake you see from them. You don't want to do that. Alexis.
Coercions and custom type parameters
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';
}
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
