|
|
feedback on MooseX::Worm
By Ricardo SIGNES at Feb 16, 2010, 04:15 am UTC
I am likely to release this code tomorrow: http://github.com/rjbs/moosex-worm It seems pretty reasonable to me, but if I'm doing something totally wrong, I'd love to find out now rather than later. More...
I am likely to release this code tomorrow:
http://github.com/rjbs/moosex-worm
It seems pretty reasonable to me, but if I'm doing something totally wrong, I'd
love to find out now rather than later.
--
rjbs
0 Replies
|
|
|
Maybe[Foo] type coercions
By Karen Etheridge at Feb 16, 2010, 12:25 am UTC
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... More...
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=>"0000-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 '0000-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, [email protected: k...@etheridge.ca] GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)0 Replies
|
|
|
$anon_class->new_object: BUILDALL is not called
By Komarov Oleg at Feb 14, 2010, 11:17 pm UTC
I've tried to dig around and to figure it out myself, but it isn't clear for me yet (whether this is a bug or a design decision): when we create an anonymous class and later create an object of this class, shouldn't new_object method call BUILDALL? It turns out that such an object isa... More...
I've tried to dig around and to figure it out myself, but it isn't
clear for me yet (whether this is a bug or a design decision):
when we create an anonymous class and later create an object of this
class, shouldn't new_object method call BUILDALL?
It turns out that such an object isa 'Moose::Object', but
Moose::Object::new isn't involved in its creation.
package Aaa;
use Moose 0.98;
sub BUILD {
print "BUILD\n";
}
package main;
Aaa->new();
use Moose::Meta::Class;
my $Bbb = Moose::Meta::Class->create_anon_class(
superclasses => ['Aaa'],
);
my $Object = $Bbb->new_object();
# Is this my job or should Moose::Meta::Class::new_object do it?
$Object->BUILDALL( $Object->BUILDARGS() );
Thanks for your time!
0 Replies
|
|
|
Documenting MooseX::Getopt edge cases
By "Ævar Arnfjörð Bjarmason" at Feb 13, 2010, 8:40 pm UTC
I got my Moose commit bit today. I added some docs on how to use MooseX::Getopt. I'd like to add more but first I have to ask if the things I want to document are sane, and there are some things I don't know how to do yet. Here are some things I've wanted to do which I haven't found in the... More...
I got my Moose commit bit today. I added some docs on how to use
MooseX::Getopt. I'd like to add more but first I have to ask if the
things I want to document are sane, and there are some things I don't
know how to do yet.
Here are some things I've wanted to do which I haven't found in the
documentation:
* Add modify the default --help output
I overrode _getopt_full_usage in my application to do this, see the
code here:
http://github.com/hinrik/hailo/blob/master/lib/Hailo.pm#L209
However I can't get this to work in the case where I supply an invalid
option, e.g. --this-does-not-exist, then I just get the default
output. There's a bug for this for my application here:
http://github.com/hinrik/hailo/issues#issue/12
* Make 'foo' equivalent to 'foo --help'
I did this simply by doing:
@ARGV = qw(--help) unless @ARGV;
Hailo->new_with_options->run;
It works, but is this a sane way to do it? I.e. something we want to
document for users?
* has help => ( ... )
How does this work? Putting it in my program magically gives me --help
but greping the source I can't find out why. Commit
47a89a8dec3d21759af9d3e9fbf06149a2870543 added support for --?,
--usage and --help but setting a help attribute only gives me the
latter.
1 Reply
|
|
|
Moose-0.97 caused a DBIx::Class test failure
By Koichi Nakatani at Feb 10, 2010, 10:31 pm UTC
Before installing Moose-0.97: $ prove -l t/storage/replication.t t/storage/replication.t .. 1/? # Using Moose version 0.96 and MooseX::Types version 0.21 t/storage/replication.t .. ok All tests successful. Files=1, Tests=132, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.64 cusr 0.10 csys = 0.78 CPU)... More...
Before installing Moose-0.97:
$ prove -l t/storage/replication.t
t/storage/replication.t .. 1/? # Using Moose version 0.96 and
MooseX::Types version 0.21
t/storage/replication.t .. ok
All tests successful.
Files=1, Tests=132, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.64
cusr 0.10 csys = 0.78 CPU)
Result: PASS
After Moose-0.97:
$ prove -l t/storage/replication.t
t/storage/replication.t .. 1/? # Using Moose version 0.97 and
MooseX::Types version 0.21
Deep recursion on subroutine
"DBIx::Class::Storage::DBI::Replicated::Replicant::debugobj" at
[...]/DBIx-Class-0.08118/lib/DBIx/Class/Storage/DBI/Replicated.pm
line 758.
Deep recursion on subroutine
"DBIx::Class::Storage::DBI::Replicated::debugobj" at
[...]/DBIx-Class-0.08118/lib/DBIx/Class/Storage/DBI/Replicated/Replicant.pm
line 69.
...and the test does not seem to come to an end.
I got the result with (hand-built) perl 5.10.1 on Mac OS X 10.6.
1 Reply
|
|
|
Non-Moose metaclasses
By Jesse Luehrs at Feb 8, 2010, 10:19 pm UTC
So, after a discussion with mst in #moose, he pointed out that initializing a non-Moose class with a Moose metaclass is a bug, and we really shouldn't be doing it. This occurs quite a bit in code within CMOP and Moose, which does things like: for my $class ($self->linearized_isa) { my $meta =... More...
So, after a discussion with mst in #moose, he pointed out that
initializing a non-Moose class with a Moose metaclass is a bug, and we
really shouldn't be doing it. This occurs quite a bit in code within
CMOP and Moose, which does things like:
for my $class ($self->linearized_isa) {
my $meta = $self->initialize($class);
...
}
and similarly with $self->superclasses, etc. When called on a Moose
class, this will initialize any non-Moose ancestors with a metaclass of
Moose::Meta::Class, which isn't really correct.
I looked into this, and it seems like the only way to accomplish this
safely is to not cache metaclasses which aren't explicitly initialized.
I've implemented this on the topic/nonmoose_gets_cmop_meta branches of
CMOP and Moose (the name is from an earlier attempt which used a
different strategy). It seems to work properly, and fixes the issues
that I've been able to find, but I was wondering if people think this is
a sane thing to want to do, or if this is going to cause other issues
down the road.
Another possible solution to this problem would be to force all classes
which get incidentally initialized like this to have CMOP metaclasses,
but this tends to break in complicated inheritance situations - for
instance, Moose::init_meta won't reinitialize a class with a CMOP
metaclass to have a Moose metaclass, it just throws an error (probably
since upgrading the metaclass in a safe way that preserves things like
existing attributes and such would be a pain). Also, in some situations,
the temporary metaclass needs to be a Moose::Meta::Class -
_fix_metaclass_incompatibility for instance doesn't exist in CMOP, so in
a Moose - non-Moose - Moose inheritance setup, the non-Moose class needs
to get a Moose metaclass to run _fix_metaclass_incompatibility on to see
if it is going to need fixing (this isn't a big deal, since metaclass
compatibility means that it needs to have a Moose metaclass anyway, but
still something to watch out for).
So... any thoughts?
-doy
1 Reply
|
|
|
Hackathon hacks?
By Dave Rolsky at Feb 5, 2010, 6:48 pm UTC
There's a hackathon here at Frozen Perl this Sunday, and I know there'll be a few folks interested in working Moose. Any thoughts on projects people could pursue? Dave Rolsky Compassionate Action for Animals - http://www.exploreveg.org/ VegGuide.Org - http://www.vegguide.org/ More...
There's a hackathon here at Frozen Perl this Sunday, and I know there'll
be a few folks interested in working Moose. Any thoughts on projects
people could pursue?
Dave Rolsky
Compassionate Action for Animals - http://www.exploreveg.org/
VegGuide.Org - http://www.vegguide.org/
1 Reply
|
|
|
Attribute initializers - incorrect documentation
By Karen Etheridge at Feb 5, 2010, 12:28 am UTC
As mentioned on #moose yesterday, I have found an inconsistency in the documentation (I don't think this is a "bug", as the actual behaviour looks reasonable and correct to me): The documentation for Class::MOP::Attribute 0.98 says: This option can be either a method name or a subroutine reference.... More...
As mentioned on #moose yesterday, I have found an inconsistency in the
documentation (I don't think this is a "bug", as the actual behaviour looks
reasonable and correct to me):
The documentation for Class::MOP::Attribute 0.98 says:
This option can be either a method name or a subroutine reference. This
method will be called when setting the attribute's value in the
constructor. Unlike default and builder, the initializer is only called
when a value is provided to the constructor. The initializer allows you
to munge this value during object construction.
..but in fact the initializer is called at any point the attribute is set
(during construction, as well as after), as demonstrated by this simple
example:
package Foo;
use Moose;
has foo => (
is => 'ro', isa => 'Int',
initializer => sub {
my ($this, $value, $setref, $attr) = @_;
print "### in foo initializer!\n";
$setref->(2 * $value);
},
default => 1,
lazy => 1,
);
has bar => (
is => 'ro', isa => 'Int',
lazy => 1,
default => sub { shift->foo + 1 },
);
sub BUILD { print "### in BUILD\n"; }
1;
perl -I. -MFoo -we'\
my $obj = Foo->new; \
print $obj->dump(1); \
print $obj->bar; \
print $obj->dump(1)'
produces the output:
### in BUILD
$VAR1 = bless( {}, 'Foo' );
### in foo initializer!
3$VAR1 = bless( {
'bar' => 3,
'foo' => 2
}, 'Foo' );
--
Show me a piano falling down a mineshaft and I'll show you A-flat minor.
. . . . .
Karen Etheridge, [email protected: k...@etheridge.ca] GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)10 Replies
|
|
|
Currying an attribute
By Buddy Burden at Jan 29, 2010, 01:14 am UTC
Guys, Not sure this is possible with the currying syntax, but imagine something similar to the following: use MooseX::Declare; class Property method get_model () { return Model->new; } class Model method foo (Property :$property) {} class PropertyModel has 'property' => ( isa => 'Property', is =>... More...
Guys,
Not sure this is possible with the currying syntax, but imagine
something similar to the following:
use MooseX::Declare;
class Property
{
method get_model () { return Model->new; }
}
class Model
{
method foo (Property :$property) {}
}
class PropertyModel
{
has 'property' => ( isa => 'Property', is => 'ro', required => 1 );
has 'model' => ( isa => 'Model', is => 'ro', lazy => 1, builder =>
'_set_model',
handles => { foo => [ foo => property
=> $self->property ] } );
method _set_model () { return $property->get_model }
}
Now, even assuming that I've dealt with the circular dependency issues
(I have, through judicious application of Class::MOP::load_class), and
furthermore assuming that Property::get_model in actuality does
something more impressive that might make it actually make _sense_ :-D
... this still doesn't work, because I can't refer to $self in a 'has'
clause. Is there a way I can make this work? Although my example has
only one method I'm trying to curry, the real code would have several,
so I'd rather not have to make a bunch of wrapper methods (though
obviously that's my fallback plan).
So is there any way to have one attribute be the argument curried to
another attribute's methods?
-- Buddy
2 Replies
|
|
|
RFC: MooseX::XPathBuilder?
By Ian Sillitoe at Jan 27, 2010, 4:15 pm UTC
Hello, I have a role lying around in my code that requires an XML source and provides a trait that allows an attribute's value to default to a specified XPath. I've found it useful as a quick way of extracting snippets of XML data into an object. I now need to refactor this out to somewhere else in... More...
Hello,
I have a role lying around in my code that requires an XML source and
provides a trait that allows an attribute's value to default to a
specified XPath. I've found it useful as a quick way of extracting
snippets of XML data into an object.
I now need to refactor this out to somewhere else in my code - so
figured it might be an appropriate time to ask if this would be useful
to stick on cpan? Clashes with other modules?
Also, the trait works by changing options through: around
'_process_options' (lazy =3D> 1 and default =3D> sub { ... }) - does that
sound sane? I couldn't see anything on the extending moose docs about
what is considered typical (or safe/stable) to hook into - is there a
consensus on this?
#################################
package PDBx::NoAtom;
use PDBx::Moose;
use MooseX::Types::Moose qw/ Str ArrayRef /;
use namespace::autoclean;
our $VERSION =3D "0.01";
with 'MooseX::XPathBuilder';
has 'id' =3D> (
=A0=A0=A0 traits=A0=A0=A0=A0=A0 =3D> [ 'XPathBuilder' ],
=A0=A0=A0 is=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D> 'ro',
=A0=A0=A0 isa=A0=A0=A0=A0=A0=A0=A0=A0 =3D> Str,
=A0=A0=A0 xpath=A0=A0=A0=A0=A0=A0 =3D> '//PDBx:entry[1]/@id',
);
map {
=A0=A0=A0 has 'primary_citation_' . $_ =3D> (
=A0=A0=A0=A0=A0=A0=A0 traits=A0=A0=A0=A0=A0 =3D> [ 'XPathBuilder' ],
=A0=A0=A0=A0=A0=A0=A0 is=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D> 'ro',
=A0=A0=A0=A0=A0=A0=A0 isa=A0=A0=A0=A0=A0=A0=A0=A0 =3D> Str,
=A0=A0=A0=A0=A0=A0=A0 xpath=A0=A0=A0=A0=A0=A0 =3D>
q{//PDBx:citationCategory/PDBx:citation[@id=3D'primary']/PDBx:} . $_,
=A0=A0=A0 );
} qw(
=A0=A0=A0 country
=A0=A0=A0 journal_abbrev
=A0=A0=A0 journal_volume
=A0=A0=A0 page_first
=A0=A0=A0 page_last
=A0=A0=A0 pdbx_database_id_PubMed
=A0=A0=A0 title
=A0=A0=A0 year
);
#################################
use PDBx::NoAtom;
my $pdb =3D PDBx::NoAtom->new( xml_file =3D> '1cuk-noatom.xml.gz' );
$pdb->id=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 # '1CUK'
$pdb->primary_citation_title;=A0=A0 # 'Crystal structure of DNA recombinati=
on
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 #=A0 protein RuvA and a model for its
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 #=A0 binding to the Holliday junction.'
#################################
All comments appreciated.
Cheers,
--
Ian Sillitoe
3 Replies
|
|
|
Method metadata (from code attributes)
By Zbigniew Lukasiak at Jan 26, 2010, 4:11 pm UTC
Hi there, I would like to add stuff to method metadata from the code attributes of their definitions (think Catalyst actions with code attributes like Local etc) - what would be the best way to do that? I tried to find the place where the Moose::Meta::Class methods hash gets initialized but with no... More...
Hi there,
I would like to add stuff to method metadata from the code attributes
of their definitions (think Catalyst actions with code attributes like
Local etc) - what would be the best way to do that? I tried to find
the place where the Moose::Meta::Class methods hash gets initialized
but with no success.
1 Reply
|
|
|
Moose::Util::MetaRole parameters passed from Moose::Exporter
By Karen Etheridge at Jan 23, 2010, 01:05 am UTC
I'm having difficulty getting some Moose::Util::MetaRole arguments passed from Moose::Exporter (specifically, I want to apply a role to a metaclass directly from an existing Moose::Exporter call). Since from the documentation this appears to be a simple task, I must have missed something, so I'm... More...
I'm having difficulty getting some Moose::Util::MetaRole arguments passed
from Moose::Exporter (specifically, I want to apply a role to a metaclass
directly from an existing Moose::Exporter call). Since from the
documentation this appears to be a simple task, I must have missed
something, so I'm going back to trying to get a simple example to work,
i.e. re-implementing MooseX::Aliases trait.
What is missing from this simple example?
package MyApp::Foo;
use MyApp::Export;
has field => ( alias => 'alias', is => 'ro', isa => 'Int' );
1;
package MyApp::Export;
use Moose ();
use Moose::Exporter;
also => [ qw(Moose) ],
# pass some arguments for Moose::Util::MetaRole to be called in
# init_meta...
class_metaroles => {
attribute => ['MooseX::Aliases::Meta::Trait::Attribute'],
# in theory, I should just have to say this to add a role to my metaclass?
# class => [ 'MyApp::Meta::Class::Trait::MyTrait' ],
},
);
no Moose;
1;
many thanks,
--
Vote Cthulhu: "For when you're tired of the lesser evil"
. . . . .
Karen Etheridge, [email protected: k...@etheridge.ca] GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)1 Reply
|
|
|
MooseX::Role::Strict + MooseX::Role::Parameterized
By Karen Etheridge at Jan 22, 2010, 10:54 am UTC
What would it take to gain the properties of MooseX::Role::Strict in MooseX::Role::Parameterized? I've been using strict roles everywhere and love them -- they've caught a few bugs that I'm sure would have been dreadful to track down otherwise; now I'm parameterizing a few of my roles and I'm... More...
What would it take to gain the properties of MooseX::Role::Strict in
MooseX::Role::Parameterized? I've been using strict roles everywhere and
love them -- they've caught a few bugs that I'm sure would have been
dreadful to track down otherwise; now I'm parameterizing a few of my roles
and I'm mourning the loss of strict checking.
I've been meaning to find the time to just sit down and do some experiments
myself (I've done a bit of meta hacking with traits and Moose::Exporter),
but I'd like to toss the question out there in case anyone else has thought
along similar lines.
--
"Vehemence is no guarantee of truth." - Isaac Asimov
. . . . .
Karen Etheridge, [email protected: k...@etheridge.ca] GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)8 Replies
|
|
|
Moose Leaking?
By Ovid at Jan 21, 2010, 1:15 pm UTC
While writing some code to track down a memory leak, I came up with the fol= lowing program using Moose 0.93. It appears to show a few leaks:=0A=0A #= !/usr/bin/env perl=0A=0A use Modern::Perl;=0A use Devel::LeakGuard::O= bject qw( GLOBAL_bless );=0A use Devel::LeakGuard::Object::State;=0A=0A = my... More...
While writing some code to track down a memory leak, I came up with the fol=
lowing program using Moose 0.93. It appears to show a few leaks:=0A=0A #=
!/usr/bin/env perl=0A=0A use Modern::Perl;=0A use Devel::LeakGuard::O=
bject qw( GLOBAL_bless );=0A use Devel::LeakGuard::Object::State;=0A=0A =
my $leakstate;=0A=0A BEGIN {=0A $leakstate =3D Devel::LeakGuard:=
:Object::State->new(=0A on_leak =3D> sub {=0A my $report =
=3D shift;=0A my @leaks =3D sort { $b->[1] <=3D> $a->[1] } # hi=
gh refcount first=0A map { [ $_ =3D> $report->{$_}[1] ] } # c=
lass, refcount=0A keys %$report;=0A printf "%-45s %s\n=
" =3D> qw/Class Refcount/;=0A say "-" x 54;=0A=0A foreach=
my $leak (@leaks) {=0A printf "%-50s %d\n" =3D> @$leak;=0A =
}=0A }=0A );=0A }=0A {=0A package Foo;=0A =
use Moose;=0A has me =3D> ( is =3D> 'rw' );=0A }=0A {=0A pa=
ckage Bar;=0A use Moose;=0A has me =3D> ( is =3D> 'rw' );=0A }=
=0A {=0A=0A package Baz;=0A sub new { bless {} =3D> shift }=0A=
}=0A my $foo =3D Foo->new;=0A $foo->me($foo);=0A my $bar =3D B=
ar->new;=0A $bar->me($bar);=0A my $baz =3D Baz->new;=0A=0AAnd the out=
put:=0A=0A Class Refcount=0A =
------------------------------------------------------=0A Class::MOP::Me=
thod::Accessor 221=0A Class::MOP::Attribute =
112=0A Class::MOP::Method =
48=0A Class::MOP::Class::Immutable::Class::MOP::Class 43=0A =
Class::MOP::Instance 32=0A Class::MOP::=
Method::Constructor 30=0A Moose::Meta::TypeConstraint=
19=0A Class::MOP::Method::Wrapped =
17=0A Class::MOP::Class 8=0A =
Moose::Meta::Method::Accessor 4=0A Moose::Meta::T=
ypeConstraint::Parameterizable 3=0A Moose::Meta::Class =
3=0A Moose::Meta::Attribute =
3=0A Class::MOP::Package 2=0A Moo=
se::Meta::TypeConstraint::Class 2=0A Moose::Meta::Instan=
ce 2=0A Bar =
1=0A Config =
1=0A Baz 1=0A Moose::M=
eta::TypeConstraint::Registry 1=0A Foo =
1=0A=0AOur actual application has some of those =
refcounts in the thousands (it gets fun when I throw Catalyst and DBIx::Cla=
ss into the mix). Am I just misunderstanding this output or does Moose lea=
k and Class::MOP leak? (I'm suspicious because it shows that Baz still has=
a refcount of one).=0A=0ACheers,=0AOvid=0A--=0ABuy the book - http=
://www.oreilly.com/catalog/perlhks/=0ATech blog - http://use.per=
l.org/~Ovid/journal/=0ATwitter - http://twitter.com/OvidPerl=
=0AOfficial Perl 6 Wiki - http://www.perlfoundation.org/perl6
1 Reply
|
|
|
TypeConstraints message
By Dermot at Jan 19, 2010, 4:59 pm UTC
Hi, I'm using the enum() constraints for a attribute. It works fine like this: has 'index_type' => ( is => 'ro', isa => enum($_, qw(for bar baz)), required => 1, But I'd like to provide a friendlier message then "Attribute of croak" definition. It looks like I have to create a subtype but I can't... More...
Hi,
I'm using the enum() constraints for a attribute. It works fine like this:
has 'index_type' => (
is => 'ro',
isa => enum($_, qw(for bar baz)),
required => 1,
);
But I'd like to provide a friendlier message then "Attribute
(index_type) does not pass the type constraint because:...5 more lines
of croak"
At this point I got stuck. I cannot add 'message' to the attribute
definition. It looks like I have to create a subtype but I can't seem
to get enum to work correctly within my subtype. This snip below will
allow ANY value.
use Moose;
use Moose::Util::TypeConstraints;
subtype 'IndexType'
=> as 'Str',
=> enum( $_, qw[foo bar baz]);
=> message { "index_type ($_) must be one of ". join
', ', qw[foo bar baz] };
has 'index_type' => (
isa => 'IndexType',
is => 'ro',
required => 1,
);
my $indexer = MyApp::Local::Indexer->new(index_type=>'foobarquin');
print "Index=$index\n";
# Index=MyApp::Local::Indexer=HASH(0x1a8fbc0)
Can anyone point me in the right direction please?
Thanks,
Dp.
6 Replies
|
|
|
Extracting the metaclass from a parameterized role
By Karen Etheridge at Jan 16, 2010, 01:12 am UTC
have been experiencing issues with my msmtp configs.) tl;dr version: no questions here, just some discoveries that I wanted to spread a little farther and get google-indexed :) A while back I posted on Stack Overflow about extracting the metaclass from inside a role definition:... More...
(Apologies if this is a dupe; I've tried sending this a few times today and
have been experiencing issues with my msmtp configs.)
tl;dr version: no questions here, just some discoveries that I wanted to
spread a little farther and get google-indexed :)
A while back I posted on Stack Overflow about extracting the metaclass from
inside a role definition:
http://stackoverflow.com/questions/1758884/how-can-i-access-the-meta-class-of-the-module-my-moose-role-is-being-applied-to
... which lead me to MooseX::Role::Parameterized (a continued two big
thumbs up BTW), which lead me to a few discoveries that I wanted to mention
here for posterity:
1. $args{consumer} only contains the metaclass of the target class at the
first level of parameterization. If the parameterized role (Role::A) is further
including another parameterized role (Role::B), then $args{consumer} in
Role::B will actually contain the metaclass of the first parameterized role
(MooseX::Role::Parameterized::Meta::Role::Parameterized), rather than
(a possible subclass of) Moose::Meta::Class.
In my application I'm nesting parameterized roles a few levels deep (the
code is cleaner this way rather than having lots of nested if statements),
so I've added a 'meta' parameter to the list of params being passed around:
# when calling the sub-role:
role {
# isa Moose::Meta::Class
my $meta = $args{consumer};
with Role::B => {
# other parameters...
metaclass => $meta,
};
};
# and in the subrole:
parameter metaclass => (
is => 'ro', isa => 'Moose::Meta::Class',
required => 1,
);
role {
# isa Moose::Meta::Class
my $meta = $params->metaclass;
# isa Moose::Object
my $consumer = $meta->name;
};
2. $args{consumer} won't even be a metaclass in the case of a role
application to a specific object instance -- in this case it will be the
type of the object being applied to.
role {
my $meta = $args{consumer};
$meta = $meta->meta if not $meta->isa('Moose::Meta::Class');
# isa Moose::Object
my $consumer = $meta->name;
};
Neither of these discoveries seemed obvious at first, so I wanted to pass
it on to save others some heartache.
I wonder if it might be useful to offer an API to extract the metaclass, as
the code above has essentially become boilerplate for all my parameterized
roles..
PS. Earlier today I was about to post here asking how one could apply a
parameterized role to an object instance (as there was no example in the
documentation), but in stepping through the Moose guts I discovered that
indeed it is just as simple as for non-parameterized roles:
my $foo = My::Foo->new();
Moose::Util::apply_all_roles($foo, My::Role, { parameter => 'value' });
2 Replies
|
|
|
MooseX::NaturalKey: stable, safe?
By Karen Etheridge at Jan 15, 2010, 01:24 am UTC
Does anyone have any opinions on MooseX::NaturalKey? Is anyone else using it? Is it stable? I'm considering using it in a production environment in combination with MooseX::Role::Parameterized; all opinions/feedback/alternative suggestions are welcome. More...
Does anyone have any opinions on MooseX::NaturalKey? Is anyone else using
it? Is it stable?
I'm considering using it in a production environment in combination with
MooseX::Role::Parameterized; all opinions/feedback/alternative suggestions
are welcome.
--
"He who knows he has enough is rich." - Tao Te Ching
. . . . .
Karen Etheridge, [email protected: k...@etheridge.ca] GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)1 Reply
|
|
|
custom trait
By Dmitry Karasik at Jan 14, 2010, 1:58 pm UTC
Hi, I'd like to ask some help with my problem with Moose. I need to create a trait, or even better an overloaded type that does special stuff with "around" accessor. Normally, one writes has x => ( is => 'rw' ); around x => \&my_accessor; I'd like to shorten that into has x => ( is => 'rw', traits... More...
Hi,
I'd like to ask some help with my problem with Moose. I need to create a
trait, or even better an overloaded type that does special stuff with "around"
accessor. Normally, one writes
has x => ( is => 'rw' ); around x => \&my_accessor;
I'd like to shorten that into
has x => ( is => 'rw', traits => ['MyAccessor']);
or even better, to
has x => ( isa => 'MyAccessor' );
possibly making MyAccessor a separate MooseX module.
I'd like to ask if you could help me here. I stopped here:
package Moose::Meta::Attribute::Custom::Trait::MyAccessor;
sub register_implementation { return 'MyAccessor' }
package MyAccessor;
use Moose::Role;
my $meta = __PACKAGE__->meta;
I thought that I should manipulate $meta, but I'm unsure how. Any ideas?
Thank you!
--
Sincerely,
Dmitry Karasik
27 Replies
|
|
|
[GitHub] pdonelan sent you a message
By GitHub at Jan 6, 2010, 07:50 am UTC
pdonelan wants you to pull from pdonelan/moose at master Body: Fixed some typos in Moose POD (mainly in Moose::Manual). You may want to skip a163994c0 which updates the example in Moose::Manual::Concepts to be the same as Moose::Manual::Roles. View repository:... More...
pdonelan wants you to pull from pdonelan/moose at master
Body: Fixed some typos in Moose POD (mainly in Moose::Manual).
You may want to skip a163994c0 which updates the example in Moose::Manual::Concepts to be the same as Moose::Manual::Roles.
View repository: http://github.com/pdonelan/moose/tree/master
0 Replies
|
|
|
Another branch to review
By autarch at Dec 30, 2009, 9:25 pm UTC
So in working on adding real attributes to roles, I've come across another thing I think needs fixing in Moose. Basically, the way MetaRole currently works is sort of broken in regards to roles, but mostly works merely by chance. Specifically, when you use MetaRole to apply roles to a metaclass,... More...
So in working on adding real attributes to roles, I've come across another
thing I think needs fixing in Moose.
Basically, the way MetaRole currently works is sort of broken in regards
to roles, but mostly works merely by chance.
Specifically, when you use MetaRole to apply roles to a metaclass, you can
pass it either a Moose::Meta::Class or a Moose::Meta::Role, and it just
goes ahead and tries to apply all the roles you give it.
That means if you supply a "method_metaclass_roles" or
"attribute_metaclass_roles" option, MetaRole tries to apply these
regardless of whether the it got a class or role.
Even worse, when you provide a metaclass_roles option, it applies this
regardless of the type of thing it got.
This is especially problematic when it comes to the integration with
Moose::Exporter and MetaRole. You can create a module (like
MooseX::Aliases) that automatically tries to apply roles to anything that
loads it.
This has mostly worked so far because (meta-)roles & classes do share a
lot of methods. However, my work on adding real attributes to roles shows
this really breaking down.
The attributes in roles, while real objects, share almost no behavior with
attributes in classes. This means that when an attribute metarole is
applied, it will often try to wrap a method that doesn't even exist for a
role attribute.
To address all this, I've created a branch called
topic/metarole-distinguishes-role-meta. It includes all the changes from
topic/roles-have-real-attributes.
Basically, this branch changes MetaRole so that if you want to apply meta
roles to anything role-related, you have to be explicit about that. All
metaclass options for roles now start with "role_", so we have
"role_metaclass_roles", "role_attribute_metaclass_roles", and so on.
For existing MX modules, adopting this is pretty simple. If you _want_ to
apply a role to both class & role metaclasses, just pass two options:
apply_metaclass_roles(
metaclass_roles => [ 'Foo' ],
role_metaclass_roles => [ 'Foo' ],
attribute_metaclass_roles => [ 'Bar' ],
role_attribute_metaclass_roles => [ 'Bar' ],
);
Simple.
If you _don't_ want to apply a role to role metaclasses, you don't pass
the option.
I think this is necessary if we want to move forward with having real
attributes in roles. The alternative would be to force modules like
MX::Aliases to use a parameterized role (uber hack) or to somehow add
useless methods to Moose::Meta::Role::Attribute (uber hack).
Obviously, this will require some changes to MX modules, but probably not
too many, and I'm happy to work on that.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
0 Replies
|
|
 | |
