perl.moose

perl.moose http://www.nntp.perl.org/group/perl.moose/ ... Copyright 1998-2013 perl.org Wed, 22 May 2013 11:49:21 +0000 ask@perl.org Re: Moose not adequately idiot-proof? by Chris Prather Sure, I was more commenting on the trade off as an aside and why it isn't in Moose core. -Chris On Monday, May 20, 2013, Darren Duncan wrote: > If that was just done as part of a test suite though, and not in > production, the performance hit might be worth it. -- Darren Duncan > > On 2013.05.20 3:07 PM, Chris Prather wrote: > >> Using the hashref directly totally circumvents moose. You would need to >> write >> something like MooseX::Globref that replaces the instance type with a >> restricted >> hash. This would seriously impact performance. >> >> -Chris >> — >> Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone >> >> >> On Mon, May 20, 2013 at 5:55 PM, Sam Brain <samb@stanford.edu >> <mailto:samb@stanford.edu>> wrote: >> >> I have a simple application which uses Moose (example copied from >> Moose::Manual::MooseX pages) >> >> package User; >> >> use Moose; >> use MooseX::StrictConstructor; >> use namespace::autoclean; >> >> has 'name' => (is => 'rw', isa => 'Str'); >> has 'email' => (is => 'rw', isa => 'Str'); >> >> package main; >> >> my $bob = User->new( name => 'Bob', email => 'bob@example.com' ); >> >> say $bob->name; # prints 'Bob' >> say $bob->naem; # Exits with error: 'Can't locate object method >> "naem" .. >> >> All is good so far. >> Then, much later, in an Idiot Moment, I forgot my "objects" were Moose >> objects and not hashrefs, and wrote: >> >> say $bob->{name}; # prints 'Bob' (!) >> >> say "OK" unless($bob->{naem}); # prints "OK", gives no error! >> >> $bob->name = "Robert"; # dies with "Can't modify non-lvalue >> subroutine >> call..." - Good! >> $bob->{name} = "Robert"; # doesn't die! >> >> say $bob->name; # prints 'Robert' (!) >> >> $bob->{naem} = "Roberto"; >> >> say $bob->{naem}; # prints 'Roberto' (!) >> >> say $bob->naem; # Exits with error: 'Can't locate object method >> "naem" ' (Whew!) >> >> say Dumper($bob); # gives: >> # $VAR1 = bless( { >> # 'email' => 'bob@example.com', >> # 'naem' => 'Roberto', >> # 'name' => 'Robert' >> # }, 'User' ); >> >> Now I know any software cannot be totally immune from extreme idiocy >> like >> mine, but I was surprised how quickly I got myself in trouble. Is >> there a >> MooseX::StrictSomething which could have help me avoided this? (Yes I >> know: >> "more exercise of the Little Grey Cells" - apart from that?) >> >> Thanks >> >> Sam Brain >> >> -- >> Sam Brain >> Department of Radiation Oncology >> Stanford Cancer Center >> Phone: 650-723-6967 >> >> >> > http://www.nntp.perl.org/group/perl.moose/2013/05/msg2641.html Mon, 20 May 2013 23:09:45 +0000 Re: Moose not adequately idiot-proof? by Darren Duncan If that was just done as part of a test suite though, and not in production, the performance hit might be worth it. -- Darren Duncan On 2013.05.20 3:07 PM, Chris Prather wrote: > Using the hashref directly totally circumvents moose. You would need to write > something like MooseX::Globref that replaces the instance type with a restricted > hash. This would seriously impact performance. > > -Chris > — > Sent from Mailbox <https://bit.ly/SZvoJe> for iPhone > > > On Mon, May 20, 2013 at 5:55 PM, Sam Brain <samb@stanford.edu > <mailto:samb@stanford.edu>> wrote: > > I have a simple application which uses Moose (example copied from > Moose::Manual::MooseX pages) > > package User; > > use Moose; > use MooseX::StrictConstructor; > use namespace::autoclean; > > has 'name' => (is => 'rw', isa => 'Str'); > has 'email' => (is => 'rw', isa => 'Str'); > > package main; > > my $bob = User->new( name => 'Bob', email => 'bob@example.com' ); > > say $bob->name; # prints 'Bob' > say $bob->naem; # Exits with error: 'Can't locate object method "naem" .. > > All is good so far. > Then, much later, in an Idiot Moment, I forgot my "objects" were Moose > objects and not hashrefs, and wrote: > > say $bob->{name}; # prints 'Bob' (!) > > say "OK" unless($bob->{naem}); # prints "OK", gives no error! > > $bob->name = "Robert"; # dies with "Can't modify non-lvalue subroutine > call..." - Good! > $bob->{name} = "Robert"; # doesn't die! > > say $bob->name; # prints 'Robert' (!) > > $bob->{naem} = "Roberto"; > > say $bob->{naem}; # prints 'Roberto' (!) > > say $bob->naem; # Exits with error: 'Can't locate object method "naem" ' (Whew!) > > say Dumper($bob); # gives: > # $VAR1 = bless( { > # 'email' => 'bob@example.com', > # 'naem' => 'Roberto', > # 'name' => 'Robert' > # }, 'User' ); > > Now I know any software cannot be totally immune from extreme idiocy like > mine, but I was surprised how quickly I got myself in trouble. Is there a > MooseX::StrictSomething which could have help me avoided this? (Yes I know: > "more exercise of the Little Grey Cells" - apart from that?) > > Thanks > > Sam Brain > > -- > Sam Brain > Department of Radiation Oncology > Stanford Cancer Center > Phone: 650-723-6967 > > http://www.nntp.perl.org/group/perl.moose/2013/05/msg2640.html Mon, 20 May 2013 23:07:22 +0000 Re: Moose not adequately idiot-proof? by Chris Prather Using the hashref directly totally circumvents  moose. You would need to write something like MooseX::Globref that replaces the instance type with a restricted hash. This would seriously impact performance. -Chris — Sent from Mailbox for iPhone On Mon, May 20, 2013 at 5:55 PM, Sam Brain <samb@stanford.edu> wrote: > I have a simple application which uses Moose (example copied from > Moose::Manual::MooseX pages) > package User; > use Moose; > use MooseX::StrictConstructor; > use namespace::autoclean; > has 'name' => (is => 'rw', isa => 'Str'); > has 'email' => (is => 'rw', isa => 'Str'); > package main; > my $bob = User->new( name => 'Bob', email => 'bob@example.com' ); > say $bob->name; # prints 'Bob' > say $bob->naem; # Exits with error: 'Can't locate object method "naem" .. > All is good so far. > Then, much later, in an Idiot Moment, I forgot my "objects" were Moose > objects and not hashrefs, and wrote: > say $bob->{name}; # prints 'Bob' (!) > say "OK" unless($bob->{naem}); # prints "OK", gives no error! > $bob->name = "Robert"; # dies with "Can't modify non-lvalue subroutine > call..." - Good! > $bob->{name} = "Robert"; # doesn't die! > say $bob->name; # prints 'Robert' (!) > $bob->{naem} = "Roberto"; > say $bob->{naem}; # prints 'Roberto' (!) > say $bob->naem; # Exits with error: 'Can't locate object method "naem" ' > (Whew!) > say Dumper($bob); # gives: > # $VAR1 = bless( { > # 'email' => 'bob@example.com', > # 'naem' => 'Roberto', > # 'name' => 'Robert' > # }, 'User' ); > Now I know any software cannot be totally immune from extreme idiocy > like mine, but I was surprised how quickly I got myself in trouble. Is > there a MooseX::StrictSomething which could have help me avoided this? > (Yes I know: "more exercise of the Little Grey Cells" - apart from that?) > Thanks > Sam Brain > -- > Sam Brain > Department of Radiation Oncology > Stanford Cancer Center > Phone: 650-723-6967 http://www.nntp.perl.org/group/perl.moose/2013/05/msg2639.html Mon, 20 May 2013 22:07:48 +0000 Moose not adequately idiot-proof? by Sam Brain I have a simple application which uses Moose (example copied from Moose::Manual::MooseX pages) package User; use Moose; use MooseX::StrictConstructor; use namespace::autoclean; has 'name' => (is => 'rw', isa => 'Str'); has 'email' => (is => 'rw', isa => 'Str'); package main; my $bob = User->new( name => 'Bob', email => 'bob@example.com' ); say $bob->name; # prints 'Bob' say $bob->naem; # Exits with error: 'Can't locate object method "naem" .. All is good so far. Then, much later, in an Idiot Moment, I forgot my "objects" were Moose objects and not hashrefs, and wrote: say $bob->{name}; # prints 'Bob' (!) say "OK" unless($bob->{naem}); # prints "OK", gives no error! $bob->name = "Robert"; # dies with "Can't modify non-lvalue subroutine call..." - Good! $bob->{name} = "Robert"; # doesn't die! say $bob->name; # prints 'Robert' (!) $bob->{naem} = "Roberto"; say $bob->{naem}; # prints 'Roberto' (!) say $bob->naem; # Exits with error: 'Can't locate object method "naem" ' (Whew!) say Dumper($bob); # gives: # $VAR1 = bless( { # 'email' => 'bob@example.com', # 'naem' => 'Roberto', # 'name' => 'Robert' # }, 'User' ); Now I know any software cannot be totally immune from extreme idiocy like mine, but I was surprised how quickly I got myself in trouble. Is there a MooseX::StrictSomething which could have help me avoided this? (Yes I know: "more exercise of the Little Grey Cells" - apart from that?) Thanks Sam Brain -- Sam Brain Department of Radiation Oncology Stanford Cancer Center Phone: 650-723-6967 http://www.nntp.perl.org/group/perl.moose/2013/05/msg2638.html Mon, 20 May 2013 21:55:25 +0000 Re: Short-circuit "before" by Chris Prather On Monday, April 29, 2013, Bill Moseley wrote: > On Mon, Apr 29, 2013 at 11:18 AM, Chris Prather <chris@prather.org<javascript:;>> > wrote: > > > On Mon, Apr 29, 2013 at 2:03 PM, Karen Etheridge <perl@froods.org<javascript:;>> > wrote: > > > > > Altneratively, you might find the augment/inner method modification > > pattern > > > to be of use -- a method can always opt to not call inner() if it has > had > > > its preconditions satisfied already. (Actually, this is probably > better > > > than my first suggestion.) > > > > > > > > I'm not sure augment/inner is ever the right answer, but it's certainly > > better than relying upon Role application order. > > > > In my case the order is not really important -- just need to find the first > one that succeeds. Although, in general I could see situation where the > order would be important. > > I'm not following the code below. Do you have an array or roles brought in > using "with"? Or instances of classes that all have an authenticate() > method? What I'm not understanding is how you are calling the > authenticate method in each role. > > The roles have been translated to objects that each implement only the authentication logic that you currently have in Roles. Perhaps the type constraint is confusing things: subtype AuthPlugin => as Object => where { $_->does('MyApp::AuthPlugin') }; # an equivalent Type Constraint which effectively is: subtype AuthPlugin => as Object => where { $_->can('authenticate') }; # equivalent to a duck_type than role_type. You then iterate over this list of objects, having each one try to authenticate accordingly. My other thought was a parameterized role where I pass in a list of > authentication classes where each has an authenticate method and then call > them in a loop as you have below. > > You could that that yes, but in my opinion it would be serious overkill. You seem to be hung up on "a solution involving Roles" when really "a solution involving delegates" would work just as well. > > -Chris http://www.nntp.perl.org/group/perl.moose/2013/04/msg2637.html Mon, 29 Apr 2013 20:00:07 +0000 Re: Short-circuit "before" by Bill Moseley On Mon, Apr 29, 2013 at 11:18 AM, Chris Prather <chris@prather.org> wrote: > On Mon, Apr 29, 2013 at 2:03 PM, Karen Etheridge <perl@froods.org> wrote: > > > Altneratively, you might find the augment/inner method modification > pattern > > to be of use -- a method can always opt to not call inner() if it has had > > its preconditions satisfied already. (Actually, this is probably better > > than my first suggestion.) > > > > > I'm not sure augment/inner is ever the right answer, but it's certainly > better than relying upon Role application order. > In my case the order is not really important -- just need to find the first one that succeeds. Although, in general I could see situation where the order would be important. I'm not following the code below. Do you have an array or roles brought in using "with"? Or instances of classes that all have an authenticate() method? What I'm not understanding is how you are calling the authenticate method in each role. My other thought was a parameterized role where I pass in a list of authentication classes where each has an authenticate method and then call them in a loop as you have below. Thanks, > > In this situation I'd argue that you want an array of Authentication > Objects that all do the same API-style role. > > role_type AuthPlugin => { role => 'MyApp::AuthPlugin' }; > > has auth_plugins => ( isa => 'ArrayRef[AuthPlugin]', traits => ['Array'], > handles => { auth_plugins => 'elements' }); > > sub authenticate { > my $self = shift; > return if $_->authenticate(@_) for $self->auth_plugins; > confess "Authentication Failed" > } > > That way you can add arbitrarily many auth plugins to the list in a > specific order. > -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.moose/2013/04/msg2636.html Mon, 29 Apr 2013 19:22:13 +0000 Re: Delete or disable a Method Modifier by Chris Prather On Mon, Apr 29, 2013 at 2:07 PM, Brian ROONEY < brian.xb.rooney@stericsson.com> wrote: > Anyone know a bit of meta or other way to delete a MM or disable a MM from > firing? > > package Stuff; > > with 'OtherStuff'; # run() > > after 'run' => sub { @_[0]->check }; > > sub check { # yadda... } > > __PACKAGE__->meta->make_immutable;no Moose;1; > > > my $p = Stuff->new; > # delete or disable MM so I can test check() autonomously > $p->run; > > $p->check; > > If this is just for testing you can add a flag to the class package Stuff; use Moose; with 'OtherStuff'; if (!$ENV{TESTING}) { after 'run' => sub { $_[0]->check }; } .... then when you want to disable those methods for testing just set $ENV{TEST} = 1 -Chris http://www.nntp.perl.org/group/perl.moose/2013/04/msg2635.html Mon, 29 Apr 2013 18:21:32 +0000 Re: Short-circuit "before" by Chris Prather On Mon, Apr 29, 2013 at 2:03 PM, Karen Etheridge <perl@froods.org> wrote: > On Mon, Apr 29, 2013 at 10:45:57AM -0700, Bill Moseley wrote: > > What we are after is somewhat of a plugin system built with Roles where a > > method in each Role is called in some defined order and once successful > no > > more are run. > > Anyone have a better suggestion than our "before authenticate" approach? > > (in principle) roles should be able to be applied in any order and not be > aware of/care about what other roles have been applied. If you need method > modifiers to be aware of each other's existence, I would suggest creating > an attribute (via another role, that the other roles would 'requires' to be > applied) which can share the necessary state information. > > Altneratively, you might find the augment/inner method modification pattern > to be of use -- a method can always opt to not call inner() if it has had > its preconditions satisfied already. (Actually, this is probably better > than my first suggestion.) > > I'm not sure augment/inner is ever the right answer, but it's certainly better than relying upon Role application order. In this situation I'd argue that you want an array of Authentication Objects that all do the same API-style role. role_type AuthPlugin => { role => 'MyApp::AuthPlugin' }; has auth_plugins => ( isa => 'ArrayRef[AuthPlugin]', traits => ['Array'], handles => { auth_plugins => 'elements' }); sub authenticate { my $self = shift; return if $_->authenticate(@_) for $self->auth_plugins; confess "Authentication Failed" } That way you can add arbitrarily many auth plugins to the list in a specific order. http://www.nntp.perl.org/group/perl.moose/2013/04/msg2634.html Mon, 29 Apr 2013 18:18:29 +0000 Delete or disable a Method Modifier by Brian ROONEY Anyone know a bit of meta or other way to delete a MM or disable a MM from firing? package Stuff; with 'OtherStuff'; # run() after 'run' => sub { @_[0]->check }; sub check { # yadda... } __PACKAGE__->meta->make_immutable;no Moose;1; my $p = Stuff->new; # delete or disable MM so I can test check() autonomously $p->run; $p->check; http://www.nntp.perl.org/group/perl.moose/2013/04/msg2633.html Mon, 29 Apr 2013 18:07:44 +0000 Re: Short-circuit "before" by Karen Etheridge On Mon, Apr 29, 2013 at 10:45:57AM -0700, Bill Moseley wrote: > What we are after is somewhat of a plugin system built with Roles where a > method in each Role is called in some defined order and once successful no > more are run. > Anyone have a better suggestion than our "before authenticate" approach? (in principle) roles should be able to be applied in any order and not be aware of/care about what other roles have been applied. If you need method modifiers to be aware of each other's existence, I would suggest creating an attribute (via another role, that the other roles would 'requires' to be applied) which can share the necessary state information. Altneratively, you might find the augment/inner method modification pattern to be of use -- a method can always opt to not call inner() if it has had its preconditions satisfied already. (Actually, this is probably better than my first suggestion.) -- Love is grand, divorce is a hundred grand. . . . . . Karen Etheridge, karen@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://www.nntp.perl.org/group/perl.moose/2013/04/msg2632.html Mon, 29 Apr 2013 18:03:45 +0000 Short-circuit "before" by Bill Moseley In an app we have an authenticate() method that either sets a flag that authentication was successful or throws an exception for failure to authenticate. Then we wanted to add two additional ways to authenticate. We created two new roles with "before authenticate" method modifiers and had each one check a flag if authentication was successful (in a previous "before") to decide to continue checking or not. Now we have more methods we wish to add. It's feeling a bit hackish at this point. What we are after is somewhat of a plugin system built with Roles where a method in each Role is called in some defined order and once successful no more are run. Anyone have a better suggestion than our "before authenticate" approach? Thanks, -- Bill Moseley moseley@hank.org http://www.nntp.perl.org/group/perl.moose/2013/04/msg2631.html Mon, 29 Apr 2013 17:46:39 +0000 Re: MooX-late-0.009 Breaks XML-Grammar-Fiction-0.12.4 by Shlomi Fish Hi Toby (and all), Please reply to all recipients. I noticed that this was fixed here - https://metacpan.org/diff/release/TOBYINK/MooX-late-0.009/TOBYINK/MooX-late-0.010 . However, it was fixed *without* an automated regression test. A regression test should definitely be added. Regards, Shlomi Fish On Tue, 23 Apr 2013 15:48:36 +0300 Shlomi Fish <shlomif@shlomifish.org> wrote: > > > Begin forwarded message: > > Date: Tue, 23 Apr 2013 09:50:01 +0100 > From: "Toby Inkster" <mail@tobyinkster.co.uk> > To: "Shlomi Fish" <shlomif@shlomifish.org> > Subject: Re: MooX-late-0.009 Breaks XML-Grammar-Fiction-0.12.4 > > > > What should be done? Can MooX::late be fixed? > > Thanks. In the latest release I simplified much of the type constraint > parsing, but it looks like I broke Maybe. It's treating it as a class > name. That is, it thinks isa=>"Maybe" means that you want an object > blessed into the "Maybe" package. > > It should be a one line fix. I'll try to release a new version today. > > -Toby > > > -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Best Introductory Programming Language - http://shlom.in/intro-lang Mastering ‘cat’ is almost as difficult as herding cats. — http://www.shlomifish.org/humour/bits/Mastering-Cat/ Please reply to list if it's a mailing list post - http://shlom.in/reply . http://www.nntp.perl.org/group/perl.moose/2013/04/msg2630.html Thu, 25 Apr 2013 08:24:51 +0000 Fw: MooX-late-0.009 Breaks XML-Grammar-Fiction-0.12.4 by Shlomi Fish Begin forwarded message: Date: Tue, 23 Apr 2013 09:50:01 +0100 From: "Toby Inkster" <mail@tobyinkster.co.uk> To: "Shlomi Fish" <shlomif@shlomifish.org> Subject: Re: MooX-late-0.009 Breaks XML-Grammar-Fiction-0.12.4 > What should be done? Can MooX::late be fixed? Thanks. In the latest release I simplified much of the type constraint parsing, but it looks like I broke Maybe. It's treating it as a class name. That is, it thinks isa=>"Maybe" means that you want an object blessed into the "Maybe" package. It should be a one line fix. I'll try to release a new version today. -Toby -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Buffy Factoids - http://www.shlomifish.org/humour/bits/facts/Buffy/ Wikipedia has a page about everything including the http://en.wikipedia.org/wiki/Kitchen_sink . Please reply to list if it's a mailing list post - http://shlom.in/reply . http://www.nntp.perl.org/group/perl.moose/2013/04/msg2629.html Tue, 23 Apr 2013 12:48:52 +0000 MooX-late-0.009 Breaks XML-Grammar-Fiction-0.12.4 by Shlomi Fish Hi all, as can be seen here: http://www.cpantesters.org/cpan/report/bad7a68b-6c66-1014-acf0-ef5eb1e9163f MooX-late-0.009 breaks https://metacpan.org/release/XML-Grammar-Fiction version 0.12.4 (And earlier versions). The way I see it, I'm doing it according to the right Moose way, and as a result I'm getting tons of error reports. What should be done? Can MooX::late be fixed? I'm including below the error report from my local machine. If I use MooX-late-0.007 all tests are fine. Regards, Shlomi Fish [DZ] building distribution under .build/m4dAnNX4S0 for installation [DZ] beginning to build XML-Grammar-Fiction [DZ] guessing dist's main_module is lib/XML/Grammar/Fiction.pm [VersionFromModule] dist version 0.12.4 (from lib/XML/Grammar/Fiction.pm) [DZ] extracting distribution abstract from lib/XML/Grammar/Fiction.pm [@Basic/ExtraTests] rewriting release test xt/release/pod-syntax.t [@Basic/ExtraTests] rewriting release test xt/release/pod-coverage.t [DZ] writing XML-Grammar-Fiction in .build/m4dAnNX4S0 Checking if your kit is complete... Looks good Writing Makefile for XML::Grammar::Fiction Writing MYMETA.yml and MYMETA.json cp lib/XML/Grammar/Fiction/FromProto/Node/Saying.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Saying.pm cp lib/XML/Grammar/Fiction/FromProto/Node/Description.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Description.pm cp lib/XML/Grammar/Screenplay/FromProto.pm blib/lib/XML/Grammar/Screenplay/FromProto.pm cp lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm blib/lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm cp lib/XML/Grammar/Fiction/ToHTML.pm blib/lib/XML/Grammar/Fiction/ToHTML.pm cp lib/XML/Grammar/Fiction/FromProto/Nodes.pm blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm cp lib/XML/Grammar/FictionBase/XSLT/Converter.pm blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm cp lib/XML/Grammar/Screenplay/ToTEI.pm blib/lib/XML/Grammar/Screenplay/ToTEI.pm cp lib/XML/Grammar/Screenplay/ToHTML.pm blib/lib/XML/Grammar/Screenplay/ToHTML.pm cp lib/XML/Grammar/Fiction/App/ToHTML.pm blib/lib/XML/Grammar/Fiction/App/ToHTML.pm cp lib/XML/Grammar/FictionBase/FromProto/Parser/XmlIterator.pm blib/lib/XML/Grammar/FictionBase/FromProto/Parser/XmlIterator.pm cp lib/XML/Grammar/Fiction/Struct/Tag.pm blib/lib/XML/Grammar/Fiction/Struct/Tag.pm cp lib/XML/Grammar/Fiction/ToDocBook.pm blib/lib/XML/Grammar/Fiction/ToDocBook.pm cp lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm blib/lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm cp lib/XML/Grammar/Screenplay/App/FromProto.pm blib/lib/XML/Grammar/Screenplay/App/FromProto.pm cp lib/XML/Grammar/Fiction/FromProto/Node/List.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/List.pm cp lib/XML/Grammar/Screenplay/ToDocBook.pm blib/lib/XML/Grammar/Screenplay/ToDocBook.pm cp lib/XML/Grammar/Fiction/FromProto/Node/Text.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Text.pm cp lib/XML/Grammar/Screenplay.pm blib/lib/XML/Grammar/Screenplay.pm cp lib/XML/Grammar/Screenplay/FromProto/Parser.pm blib/lib/XML/Grammar/Screenplay/FromProto/Parser.pm cp lib/XML/Grammar/Fiction/RNG_Renderer.pm blib/lib/XML/Grammar/Fiction/RNG_Renderer.pm cp lib/XML/Grammar/FictionBase/TagsTree2XML.pm blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm cp lib/XML/Grammar/Screenplay/App/ToDocBook.pm blib/lib/XML/Grammar/Screenplay/App/ToDocBook.pm cp lib/XML/Grammar/Fiction/App/ToDocBook.pm blib/lib/XML/Grammar/Fiction/App/ToDocBook.pm cp lib/XML/Grammar/Fiction/FromProto/Node/InnerDesc.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/InnerDesc.pm cp lib/XML/Grammar/FictionBase/FromProto/Parser/LineIterator.pm blib/lib/XML/Grammar/FictionBase/FromProto/Parser/LineIterator.pm cp lib/XML/Grammar/Fiction/FromProto/Node/Comment.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Comment.pm cp lib/XML/Grammar/Fiction/FromProto/Node/WithContent.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/WithContent.pm cp lib/XML/Grammar/Screenplay/Base.pm blib/lib/XML/Grammar/Screenplay/Base.pm cp lib/XML/Grammar/Fiction/FromProto/Node/Element.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Element.pm cp lib/XML/Grammar/Fiction/FromProto/Parser.pm blib/lib/XML/Grammar/Fiction/FromProto/Parser.pm cp lib/XML/Grammar/Fiction/FromProto/Node/Paragraph.pm blib/lib/XML/Grammar/Fiction/FromProto/Node/Paragraph.pm cp lib/XML/Grammar/Fiction/FromProto.pm blib/lib/XML/Grammar/Fiction/FromProto.pm cp lib/XML/Grammar/Screenplay/XSLT/Base.pm blib/lib/XML/Grammar/Screenplay/XSLT/Base.pm cp lib/XML/Grammar/Fiction/FromProto/Node.pm blib/lib/XML/Grammar/Fiction/FromProto/Node.pm cp lib/XML/Grammar/Fiction.pm blib/lib/XML/Grammar/Fiction.pm cp lib/XML/Grammar/Fiction/Err.pm blib/lib/XML/Grammar/Fiction/Err.pm cp lib/XML/Grammar/Fiction/App/FromProto.pm blib/lib/XML/Grammar/Fiction/App/FromProto.pm cp lib/XML/Grammar/FictionBase/Event.pm blib/lib/XML/Grammar/FictionBase/Event.pm cp lib/XML/Grammar/Screenplay/App/ToHTML.pm blib/lib/XML/Grammar/Screenplay/App/ToHTML.pm Manifying blib/man3/XML::Grammar::Screenplay::FromProto::Parser::QnD.3pm Manifying blib/man3/XML::Grammar::Screenplay::ToTEI.3pm Manifying blib/man3/XML::Grammar::Fiction::App::ToHTML.3pm Manifying blib/man3/XML::Grammar::Screenplay::ToHTML.3pm Manifying blib/man3/XML::Grammar::FictionBase::FromProto::Parser::XmlIterator.3pm Manifying blib/man3/XML::Grammar::Fiction::Struct::Tag.3pm Manifying blib/man3/XML::Grammar::Fiction::ToDocBook.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Parser::QnD.3pm Manifying blib/man3/XML::Grammar::Screenplay::App::FromProto.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::List.3pm Manifying blib/man3/XML::Grammar::Screenplay::ToDocBook.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Text.3pm Manifying blib/man3/XML::Grammar::Screenplay.3pm Manifying blib/man3/XML::Grammar::Screenplay::FromProto::Parser.3pm Manifying blib/man3/XML::Grammar::Fiction::RNG_Renderer.3pm Manifying blib/man3/XML::Grammar::FictionBase::TagsTree2XML.3pm Manifying blib/man3/XML::Grammar::Fiction::App::ToDocBook.3pm Manifying blib/man3/XML::Grammar::Screenplay::App::ToDocBook.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::InnerDesc.3pm Manifying blib/man3/XML::Grammar::FictionBase::FromProto::Parser::LineIterator.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Comment.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Saying.3pm Manifying blib/man3/XML::Grammar::Screenplay::FromProto.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Description.3pm Manifying blib/man3/XML::Grammar::Fiction::ToHTML.3pm Manifying blib/man3/XML::Grammar::FictionBase::XSLT::Converter.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Nodes.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Element.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Parser.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node.3pm Manifying blib/man3/XML::Grammar::Fiction.3pm Manifying blib/man3/XML::Grammar::Fiction::Err.3pm Manifying blib/man3/XML::Grammar::FictionBase::Event.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::WithContent.3pm Manifying blib/man3/XML::Grammar::Screenplay::Base.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto::Node::Paragraph.3pm Manifying blib/man3/XML::Grammar::Screenplay::XSLT::Base.3pm Manifying blib/man3/XML::Grammar::Fiction::FromProto.3pm Manifying blib/man3/XML::Grammar::Fiction::App::FromProto.3pm Manifying blib/man3/XML::Grammar::Screenplay::App::ToHTML.3pm PERL_DL_NONLAZY=1 /usr/bin/perl5.16.3 "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/base/*.t t/fiction/*.t t/screenplay/*.t type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at lib/XML/Grammar/Fiction/App/FromProto.pm line 15. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/App/FromProto.pm line 15. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::App::FromProto loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::App::FromProto ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto::Node::Element loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto::Node::Element ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto::Node::InnerDesc loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto::Node::InnerDesc ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto::Node::Paragraph loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto::Node::Paragraph ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto::Nodes loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto::Nodes ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm line 10. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::FromProto::Parser::QnD loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::FromProto::Parser::QnD ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/Fiction/Struct/Tag.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/Struct/Tag.pm line 10. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Fiction::Struct::Tag loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Fiction::Struct::Tag ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/Event.pm line 6. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/Event.pm line 6. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::FictionBase::Event loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::FictionBase::Event ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/Fiction/Struct/Tag.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/Struct/Tag.pm line 10. Compilation failed in require at lib/XML/Grammar/FictionBase/FromProto/Parser/XmlIterator.pm line 11. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/FromProto/Parser/XmlIterator.pm line 11. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::FictionBase::FromProto::Parser::XmlIterator loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::FictionBase::FromProto::Parser::XmlIterator ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::FictionBase::TagsTree2XML loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::FictionBase::TagsTree2XML ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at lib/XML/Grammar/Screenplay/App/FromProto.pm line 13. BEGIN failed--compilation aborted at lib/XML/Grammar/Screenplay/App/FromProto.pm line 13. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Screenplay::App::FromProto loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Screenplay::App::FromProto ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Screenplay::FromProto loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Screenplay::FromProto ok)' type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm line 10. BEGIN failed--compilation aborted at lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm line 10. Compilation failed in require at -e line 1. # Failed test 'XML::Grammar::Screenplay::FromProto::Parser::QnD loaded ok' # at t/00-compile.t line 62. # '' # doesn't match '(?^s:^\s*XML::Grammar::Screenplay::FromProto::Parser::QnD ok)' # Looks like you failed 14 tests of 42. t/00-compile.t ........................................ Dubious, test returned 14 (wstat 3584, 0xe00) Failed 14/42 subtests # # # Compiled against libxml2 version: 20900 # Running libxml2 version: 20900 # t/00-libxml-basic.t ................................... ok t/00-load.t ........................................... ok Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/app-to-html.t ....................................... ok t/base/line-iterator-unit.t ........................... ok t/boilerplate.t ....................................... ok type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at t/fiction/proto-text-invalid.t line 12. BEGIN failed--compilation aborted at t/fiction/proto-text-invalid.t line 12. # Looks like your test exited with 255 before it could output anything. t/fiction/proto-text-invalid.t ........................ Dubious, test returned 255 (wstat 65280, 0xff00) Failed 26/26 subtests type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at t/fiction/proto-text-to-xml-using-custom-parser.t line 13. BEGIN failed--compilation aborted at t/fiction/proto-text-to-xml-using-custom-parser.t line 13. # Looks like your test exited with 255 before it could output anything. t/fiction/proto-text-to-xml-using-custom-parser.t ..... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 29/29 subtests type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Parser/QnD.pm line 10. Compilation failed in require at t/fiction/qnd-parser-unit.t line 6. BEGIN failed--compilation aborted at t/fiction/qnd-parser-unit.t line 6. # Looks like your test exited with 255 before it could output anything. t/fiction/qnd-parser-unit.t ........................... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 3/3 subtests Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/fiction/to-docbook.t ................................ ok Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/fiction/to-xhtml.t .................................. ok t/pod-coverage.t ...................................... ok t/pod.t ............................................... ok t/release-pod-coverage.t .............................. skipped: these tests are for release candidate testing t/release-pod-syntax.t ................................ skipped: these tests are for release candidate testing t/screenplay/00-load.t ................................ ok Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/screenplay/app-to-html.t ............................ ok t/screenplay/boilerplate.t ............................ ok type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at t/screenplay/proto-text-invalid.t line 12. BEGIN failed--compilation aborted at t/screenplay/proto-text-invalid.t line 12. # Looks like your test exited with 255 before it could output anything. t/screenplay/proto-text-invalid.t ..................... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/2 subtests type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/TagsTree2XML.pm line 10. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.16.2/Module/Runtime.pm line 317. Compilation failed in require at t/screenplay/proto-text-to-xml-using-custom-parser.t line 14. # Looks like your test exited with 255 before it could output anything. t/screenplay/proto-text-to-xml-using-custom-parser.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 54/54 subtests type 'Maybe' does not accept parameters at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/MooX/late.pm line 246. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Fiction/FromProto/Nodes.pm line 14. Compilation failed in require at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm line 10. BEGIN failed--compilation aborted at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/Screenplay/FromProto/Parser/QnD.pm line 10. Compilation failed in require at t/screenplay/qnd-parser-unit.t line 6. BEGIN failed--compilation aborted at t/screenplay/qnd-parser-unit.t line 6. # Looks like your test exited with 255 before it could output anything. t/screenplay/qnd-parser-unit.t ........................ Dubious, test returned 255 (wstat 65280, 0xff00) Failed 3/3 subtests Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/screenplay/to-docbook.t ............................. ok Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/screenplay/to-tei.t ................................. ok Type constraint 'XML::LibXML::RelaxNG' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:18, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXML' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:19, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. Type constraint 'XML::LibXSLT::StylesheetWrapper' not fully enforced (defined at /home/shlomif/progs/perl/cpan/XML/Grammar/Fiction/trunk/perl/modules/XML-Grammar-Fiction/.build/m4dAnNX4S0/blib/lib/XML/Grammar/FictionBase/XSLT/Converter.pm:20, package XML::Grammar::FictionBase::XSLT::Converter) at /home/shlomif/apps/perl/modules/lib/perl5/site_perl/5.16.3/Type/Tiny.pm line 202. t/screenplay/to-xhtml.t ............................... ok t/style-trailing-space.t .............................. ok Test Summary Report ------------------- t/00-compile.t (Wstat: 3584 Tests: 42 Failed: 14) Failed tests: 2, 6, 10-11, 13, 17, 19, 21, 24, 26-27 30, 34, 36 Non-zero exit status: 14 t/fiction/proto-text-invalid.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 26 tests but ran 0. t/fiction/proto-text-to-xml-using-custom-parser.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 29 tests but ran 0. t/fiction/qnd-parser-unit.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 3 tests but ran 0. t/screenplay/proto-text-invalid.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 2 tests but ran 0. t/screenplay/proto-text-to-xml-using-custom-parser.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 54 tests but ran 0. t/screenplay/qnd-parser-unit.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 3 tests but ran 0. Files=25, Tests=238, 6 wallclock secs ( 0.11 usr 0.02 sys + 5.67 cusr 0.60 csys = 6.40 CPU) Result: FAIL Failed 7/25 test programs. 14/238 subtests failed. make: *** [test_dynamic] Error 255 error running make test -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Parody of "The Fountainhead" - http://shlom.in/towtf If his programming is anything like his philosophising, he would find ten imaginary bugs in the “Hello World” program. Please reply to list if it's a mailing list post - http://shlom.in/reply . http://www.nntp.perl.org/group/perl.moose/2013/04/msg2628.html Tue, 23 Apr 2013 05:51:14 +0000 PDLv3 engine based on Moo[se] by Chris Marshall Hi- I'm new to the Moose mailing list. I've just proposed a new implementation for the Perl Data Language computational engine based on Moo[se] and MOP. I'm relatively new to Moose stuff and some of my thoughts seem plausible (to me) but I would be very interested in feedback on the ideas in this proposal. http://mailman.jach.hawaii.edu/pipermail//pdl-porters/2013-April/005543.html Thanks much, Chris http://www.nntp.perl.org/group/perl.moose/2013/04/msg2627.html Sun, 21 Apr 2013 22:53:50 +0000 Moose course in London by Dave Cross Hi all, This Saturday (6th April) I'm running a one-day course on "Object Oriented Programming with Perl and Moose" in London. I ran a taster extract from this course at the LPW last November, but this is the full six-hour version. Tickets are £30. More information and a booking form are available on the Perl School web site at: http://perlschool.co.uk/courses/object-oriented-programming-with-perl-and-moose/ It's likely, of course, that most people reading this mailing list are in no need of Moose training from me. But perhaps you could pass the details on to you less Moose-y colleagues. Cheers, Dave... http://www.nntp.perl.org/group/perl.moose/2013/04/msg2626.html Tue, 02 Apr 2013 12:24:44 +0000 MooseX::Privacy by thiagoglauco Hi, folks. My name is Thiago and I'm a Perl programmer from Brazil. I'm having a very good time using MooseX::Privacy,. Afterall I'm facing a little trouble, when using MooseX::Privacy inside a Moose::Role. MooseX::Privacy::Trait::Role works good with attributes but private_methods does not work inside the role. Have you even faced this issue? Is there some trick I missed? thanks for your help. ________________________________________ Thiago Glauco Sanchez - Petrobras SA ITIL Enterasys Certified Expert - Networking Modulo Certified Security Office tel: 55 11 3523-9756 "O emitente desta mensagem � respons�vel por seu conte�do e endere�amento. Cabe ao destinat�rio cuidar quanto ao tratamento adequado. Sem a devida autoriza��o, a divulga��o, a reprodu��o, a distribui��o ou qualquer outra a��o em desconformidade com as normas internas do Sistema Petrobras s�o proibidas e pass�veis de san��o disciplinar, c�vel e criminal." "The sender of this message is responsible for its content and addressing. The receiver shall take proper care of it. Without due authorization, the publication, reproduction, distribution or the performance of any other action not conforming to Petrobras System internal policies and procedures is forbidden and liable to disciplinary, civil or criminal sanctions." "El emisor de este mensaje es responsable por su contenido y direccionamiento. Cabe al destinatario darle el tratamiento adecuado. Sin la debida autorizaci�n, su divulgaci�n, reproducci�n, distribuci�n o cualquier otra acci�n no conforme a las normas internas del Sistema Petrobras est�n prohibidas y ser�n pasibles de sanci�n disciplinaria, civil y penal." http://www.nntp.perl.org/group/perl.moose/2013/04/msg2625.html Tue, 02 Apr 2013 04:06:16 +0000 Re: Announcement: Moose 2.0800 is released! by Kent Fredric On 30 March 2013 08:10, Chris Prather <chris@prather.org> wrote: > Excludes specifically (silently) encourages people to break the > contract nature (allomorphism?) of Roles. That is you can suddenly no > longer have an API that the Role claims you *should* have because you > excluded the method on composition. Additionally the excludes/alias > feature *only* exists for Roles in the core. That sounds like the usage of alias/excludes should have a default stricture that they may be only used if-and-only-if doing so doesn't break the role criteria. So alias/excluding "foo" out of the picture should add a < requires foo > equivalent to the role that has to be resolved at some later stage somehow. at least, that way, people can use it for "useful" purposes without it resulting in an interface contract breach. Sample Usage Might be: - package A; use Moose::Role; sub foo { }; - package B; use Moose::Role; with 'B' => { excludes => [ 'foo' ] } - package C; use Moose; with 'B; # C must declare 'foo' - Or with Aliases; - package A; use Moose::Role; sub foo { }; - package B; use Moose::Role; with 'B' => { alias => { 'foo' => 'A_Foo' } } sub B_Foo { } - package C; use Moose; with 'B; # C must declare 'foo' sub foo { $_[0]->A_Foo + $_[0]->B_Foo } -- kentnl http://www.nntp.perl.org/group/perl.moose/2013/03/msg2624.html Sat, 30 Mar 2013 16:27:31 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Prather On Fri, Mar 29, 2013 at 2:58 PM, Chris Weyl <cweyl@alumni.drew.edu> wrote: > > I'm still not seeing any compelling reason to drop excludes/alias. Am I > missing something here, like is the existence of alias/excludes in core > blocking Some Thing Good, or encouraging Very Bad Behaviour? The latter actually. Excludes specifically (silently) encourages people to break the contract nature (allomorphism?) of Roles. That is you can suddenly no longer have an API that the Role claims you *should* have because you excluded the method on composition. Additionally the excludes/alias feature *only* exists for Roles in the core. So the place we are in now is we have extra code for an inconsistent feature that can encourage bad behavior. I can see validity to the argument that this feature could be cut and replaced with either referring people like yourself to MooseX::Aliases ... or simply core-ing MX::Aliases and making the alias feature more consistent and useful. Note we haven't *actually* cut anything yet. All of this is about potentially deprecating and cutting them in the future. So possibly this discussion is pre-mature too. -Chris http://www.nntp.perl.org/group/perl.moose/2013/03/msg2623.html Fri, 29 Mar 2013 19:10:40 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Weyl On Fri, Mar 29, 2013 at 11:49 AM, Chris Prather <chris@prather.org> wrote: > On Fri, Mar 29, 2013 at 2:44 PM, Chris Weyl <cweyl@alumni.drew.edu> wrote: > > To clarify here: "Aliasing allows me to trivially shunt one method aside > > and create a new one in its place *while still being able to use the > > previous method* w/o having to resort to method modifiers." > > To quote doy when I brought up this same point (with an entirely > different phrasing) in this same thread: > > > > > In that sense, there's no reason that this should be a role-specific > > feature, and that's why MooseX::Aliases exists to begin with. > The existence of a MX module that can serve the same functionality is not, in and of itself, a reason to drop core functionality. If that were the case, then we should never have included MX::AttributeHandlers in core. I'm still not seeing any compelling reason to drop excludes/alias. Am I missing something here, like is the existence of alias/excludes in core blocking Some Thing Good, or encouraging Very Bad Behaviour? -Chris -- Chris Weyl Ex astris scientia http://www.nntp.perl.org/group/perl.moose/2013/03/msg2622.html Fri, 29 Mar 2013 18:58:52 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Prather On Fri, Mar 29, 2013 at 2:44 PM, Chris Weyl <cweyl@alumni.drew.edu> wrote: > On Fri, Mar 29, 2013 at 10:32 AM, Chris Weyl <cweyl@alumni.drew.edu> wrote: > >> https://gist.github.com/c29c165e1aacda7018a5 >> >> Aliasing allows me to trivially shunt one method aside and create a new >> one in its place w/o having to resort to method modifiers. >> > > To clarify here: "Aliasing allows me to trivially shunt one method aside > and create a new one in its place *while still being able to use the > previous method* w/o having to resort to method modifiers." To quote doy when I brought up this same point (with an entirely different phrasing) in this same thread: > > In that sense, there's no reason that this should be a role-specific > feature, and that's why MooseX::Aliases exists to begin with. > > -doy -Chris http://www.nntp.perl.org/group/perl.moose/2013/03/msg2621.html Fri, 29 Mar 2013 18:49:23 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Weyl On Fri, Mar 29, 2013 at 10:32 AM, Chris Weyl <cweyl@alumni.drew.edu> wrote: > https://gist.github.com/c29c165e1aacda7018a5 > > Aliasing allows me to trivially shunt one method aside and create a new > one in its place w/o having to resort to method modifiers. > To clarify here: "Aliasing allows me to trivially shunt one method aside and create a new one in its place *while still being able to use the previous method* w/o having to resort to method modifiers." -- Chris Weyl Ex astris scientia http://www.nntp.perl.org/group/perl.moose/2013/03/msg2620.html Fri, 29 Mar 2013 18:45:07 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Weyl On Fri, Mar 29, 2013 at 10:50 AM, Jesse Luehrs <doy@tozt.net> wrote: > return > $self->Moose::Meta::Method::Accessor::Native::Array::grep::_return_value("[ > keys %{ $slot_access } ]"); > Yes, technically that would work, but.... why would hardcoding package names be better? -Chris -- Chris Weyl Ex astris scientia http://www.nntp.perl.org/group/perl.moose/2013/03/msg2619.html Fri, 29 Mar 2013 18:43:29 +0000 Re: Announcement: Moose 2.0800 is released! by Jesse Luehrs On Fri, Mar 29, 2013 at 10:32:53AM -0700, Chris Weyl wrote: > On Fri, Mar 29, 2013 at 9:35 AM, Jesse Luehrs <doy@tozt.net> wrote: > > > On Fri, Mar 29, 2013 at 09:30:59AM -0700, Chris Weyl wrote: > > > On Thu, Mar 28, 2013 at 10:34 AM, Jesse Luehrs <doy@tozt.net> wrote: > > > > > > > On Thu, Mar 28, 2013 at 06:23:55PM +0100, curtis_ovid_poe wrote: > > > > > Is the idea of deprecating alias and excludes just speculation, or is > > > > > this the plan for the future? > > > > > > > > It has always been my plan, but it's been a while since I discussed it > > > > with anyone. > > > > > > > > > > Why would we do that? Those are extremely useful features, and I'm > > having > > > a hard time visualizing a benefit to removing method aliasing and > > exclusion. > > > > What do you use them for? > > > > One example would be an extension in providing a new native trait accessor > type... (that I've had hanging out in an attic branch forever): > > https://gist.github.com/c29c165e1aacda7018a5 > > Aliasing allows me to trivially shunt one method aside and create a new one > in its place w/o having to resort to method modifiers. As I described earlier, this works fine: package Moose::Meta::Method::Accessor::Native::Hash::grep_keys; use Moose::Role 1.15; with 'Moose::Meta::Method::Accessor::Native::Array::grep', 'Moose::Meta::Method::Accessor::Native::Hash', ; sub _return_value { my ($self, $slot_access) = @_; return $self->Moose::Meta::Method::Accessor::Native::Array::grep::_return_value("[ keys %{ $slot_access } ]"); } no Moose::Role; 1; -doy http://www.nntp.perl.org/group/perl.moose/2013/03/msg2618.html Fri, 29 Mar 2013 17:50:36 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Weyl On Fri, Mar 29, 2013 at 9:35 AM, Jesse Luehrs <doy@tozt.net> wrote: > On Fri, Mar 29, 2013 at 09:30:59AM -0700, Chris Weyl wrote: > > On Thu, Mar 28, 2013 at 10:34 AM, Jesse Luehrs <doy@tozt.net> wrote: > > > > > On Thu, Mar 28, 2013 at 06:23:55PM +0100, curtis_ovid_poe wrote: > > > > Is the idea of deprecating alias and excludes just speculation, or is > > > > this the plan for the future? > > > > > > It has always been my plan, but it's been a while since I discussed it > > > with anyone. > > > > > > > Why would we do that? Those are extremely useful features, and I'm > having > > a hard time visualizing a benefit to removing method aliasing and > exclusion. > > What do you use them for? > One example would be an extension in providing a new native trait accessor type... (that I've had hanging out in an attic branch forever): https://gist.github.com/c29c165e1aacda7018a5 Aliasing allows me to trivially shunt one method aside and create a new one in its place w/o having to resort to method modifiers. -- Chris Weyl Ex astris scientia http://www.nntp.perl.org/group/perl.moose/2013/03/msg2617.html Fri, 29 Mar 2013 17:33:22 +0000 Re: Announcement: Moose 2.0800 is released! by Jesse Luehrs On Fri, Mar 29, 2013 at 12:56:11PM -0400, Chris Prather wrote: > On Fri, Mar 29, 2013 at 11:12 AM, Jesse Luehrs <doy@tozt.net> wrote: > > > > > sub programmer_pay_rate { shift->R::Programmer::pay_rate } > > > > Keeping alias as a clean way of generating this exact kind of delegate > might be a valid / useful thing and inline with how handles and other > delegates work. It is also a much less *common* thing, and excludes > has no such justification that I can see. In that sense, there's no reason that this should be a role-specific feature, and that's why MooseX::Aliases exists to begin with. -doy http://www.nntp.perl.org/group/perl.moose/2013/03/msg2616.html Fri, 29 Mar 2013 17:09:22 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Prather On Fri, Mar 29, 2013 at 11:12 AM, Jesse Luehrs <doy@tozt.net> wrote: > > sub programmer_pay_rate { shift->R::Programmer::pay_rate } > Keeping alias as a clean way of generating this exact kind of delegate might be a valid / useful thing and inline with how handles and other delegates work. It is also a much less *common* thing, and excludes has no such justification that I can see. -Chris http://www.nntp.perl.org/group/perl.moose/2013/03/msg2615.html Fri, 29 Mar 2013 16:56:22 +0000 Re: Announcement: Moose 2.0800 is released! by Jesse Luehrs On Fri, Mar 29, 2013 at 09:30:59AM -0700, Chris Weyl wrote: > On Thu, Mar 28, 2013 at 10:34 AM, Jesse Luehrs <doy@tozt.net> wrote: > > > On Thu, Mar 28, 2013 at 06:23:55PM +0100, curtis_ovid_poe wrote: > > > Is the idea of deprecating alias and excludes just speculation, or is > > > this the plan for the future? > > > > It has always been my plan, but it's been a while since I discussed it > > with anyone. > > > > Why would we do that? Those are extremely useful features, and I'm having > a hard time visualizing a benefit to removing method aliasing and exclusion. What do you use them for? -doy http://www.nntp.perl.org/group/perl.moose/2013/03/msg2614.html Fri, 29 Mar 2013 16:35:55 +0000 Re: Announcement: Moose 2.0800 is released! by Chris Weyl On Thu, Mar 28, 2013 at 10:34 AM, Jesse Luehrs <doy@tozt.net> wrote: > On Thu, Mar 28, 2013 at 06:23:55PM +0100, curtis_ovid_poe wrote: > > Is the idea of deprecating alias and excludes just speculation, or is > > this the plan for the future? > > It has always been my plan, but it's been a while since I discussed it > with anyone. > Why would we do that? Those are extremely useful features, and I'm having a hard time visualizing a benefit to removing method aliasing and exclusion. -Chris -- Chris Weyl Ex astris scientia http://www.nntp.perl.org/group/perl.moose/2013/03/msg2613.html Fri, 29 Mar 2013 16:31:33 +0000 Re: Announcement: Moose 2.0800 is released! by Lars Balker On Fri, Mar 29, 2013 at 4:04 PM, Ovid <curtis_ovid_poe@yahoo.com> wrote: >>> > with 'R::Programmer'; >>> > with 'R::Clerk'; > I think you may have misread the code. He composed them separately because if he composed them at the same time, he would get a conflict: > > Due to a method name conflict in roles 'R::Clerk' and 'R::Programmer', > the method 'pay_rate' must be implemented or excluded by 'R::Employee' at ... > > Thus, in this instance, he was forced to compose those roles separately (since "exclude" is going to be taken away) and lose compositional safety. I had a choice between the above and with 'R::Programmer', 'R::Clerk'; sub pay_rate { "nonsensical return value, because the modelling is weird" } Both work, both are nasty. -- Lars Balker Consult::Perl http://www.nntp.perl.org/group/perl.moose/2013/03/msg2612.html Fri, 29 Mar 2013 15:14:57 +0000 Re: Announcement: Moose 2.0800 is released! by Jesse Luehrs On Fri, Mar 29, 2013 at 08:04:31AM -0700, Ovid wrote: > ----- Original Message ----- > > > From: Jesse Luehrs <doy@tozt.net> > > On Fri, Mar 29, 2013 at 05:34:50AM -0700, Ovid wrote: > >> ----- Original Message ----- > >> > >> > From: Lars Balker <lars@balker.dk> > >> > > >> > As Jesse's earlier example showed, instead of excluding and > > aliasing, > >> > just refer to the methods directly within the roles: > >> > > >> > use v5.10.0; > >> > { package R::Programmer; use Moose::Role; sub pay_rate {12} } > >> > { package R::Clerk;      use Moose::Role; sub pay_rate {10} } > >> > { package R::Employee;   use Moose; > >> >   with 'R::Programmer'; > >> >   with 'R::Clerk'; > >> >   has [qw/programming_hours drudgery/] => ( is => 'ro' > > ); > >> >   sub paycheck { > >> >       my $self = shift; > >> >       return $self->R::Programmer::pay_rate * > > $self->programming_hours > >> >           + $self->R::Clerk::pay_rate      * $self->drudgery; > >> >   } > >> > } > >> > my $employee = R::Employee->new( > >> >     programming_hours => 15, > >> >     drudgery          => 25, > >> > ); > >> > say $employee->paycheck; > >> > >> > >> With 'R::Programmer' and 'R::Clerk' composed on separate > > lines, you no > >> longer get compositional safety and roles become little more than > >> glorified mixins. These were problems that roles/traits were designed > >> to fix. This is not an improvement. > > > > There's no need to actually compose them separately, things work just > > fine if you compose them on the same line. > > I think you may have misread the code. He composed them separately because if he composed them at the same time, he would get a conflict: > >     Due to a method name conflict in roles 'R::Clerk' and 'R::Programmer',  >     the method 'pay_rate' must be implemented or excluded by 'R::Employee' at ... > > Thus, in this instance, he was forced to compose those roles > separately (since "exclude" is going to be taken away) and lose > compositional safety. I did misread. In this case though, this is something that you shouldn't even be allowed to do in the first place, and the fact that Moose allows it is arguably a bug. You're consuming a role which provides a pay_rate method, but then you aren't providing a pay_rate method yourself. This entirely breaks the concept of a role interface as a contract. > >> And I should not have to hardcode the class names into my method > >> names. That's a hack that we sometimes fall back on to work around MI > >> limitations when you're trying to call an otherwise unreachable method > >> and now it's bubbling up into roles? > > > > How is this meaningfully different? You're already hardcoding the role > > names at the point where you consume them. > > > For the same reason that any cutting-and-pasting is a bad idea: our > role as programmers is to minimize code duplication as much as > possible to ensure that when we do have to change something, we > minimize the number of places where said change needs to be made. I > would much rather switch the name of the role I'm using at the top of > my class and know that things *just work* (again, as was part of the > original intent of Smalltalk traits) instead of having to remember to > do a search and replace for every place where I've had to hard-code a > package name. > > I could also easily see someone subclassing "Employee" and now having > to remember that if they want pay_rate, it's > either $self->R::Clerk::pay_rate or $self->R::Programmer::pay_rate . > The subclass *shouldn't* have to know the implementation details of > Employee to make this work. Piers' solution of using > "*programmer_pay_rate = \&R::Programmer::pay_rate is" is ugly, but > it's marginally better. However, that's the sort of scaffolding code > that roles were (pardon the broken record) designed to handle. The > tools to get this right are already in Moose, so I'm really confused > about what's going on here. You shouldn't ever need to access the individual implementations of R::Clerk::pay_rate or R::Programmer::pay_rate except from within the role or class that composes them. Doing otherwise also defeats the purpose of a role as an interface contract. If you want to provide that information, you should write it as an actual method sub programmer_pay_rate { shift->R::Programmer::pay_rate } > I ask again: what benefit from removing 'alias' and 'exclude' is so > strong that it's worth removing a tool that Moose has provided for > years? Every example you've given so far seems to be an abuse of the role system. I still have yet to see an example where alias or excludes is used in a way that makes sense (and as I mentioned before, I have never once had a reason to use alias or excludes except to work around the issue that is fixed in Moose 2.08). -doy http://www.nntp.perl.org/group/perl.moose/2013/03/msg2611.html Fri, 29 Mar 2013 15:13:04 +0000 Re: Announcement: Moose 2.0800 is released! by Ovid ----- Original Message ----- > From: Jesse Luehrs <doy@tozt.net> > On Fri, Mar 29, 2013 at 05:34:50AM -0700, Ovid wrote: >> ----- Original Message ----- >> >> > From: Lars Balker <lars@balker.dk> >> > >> > As Jesse's earlier example showed, instead of excluding and > aliasing, >> > just refer to the methods directly within the roles: >> > >> > use v5.10.0; >> > { package R::Programmer; use Moose::Role; sub pay_rate {12} } >> > { package R::Clerk;      use Moose::Role; sub pay_rate {10} } >> > { package R::Employee;   use Moose; >> >   with 'R::Programmer'; >> >   with 'R::Clerk'; >> >   has [qw/programming_hours drudgery/] => ( is => 'ro' > ); >> >   sub paycheck { >> >       my $self = shift; >> >       return $self->R::Programmer::pay_rate * > $self->programming_hours >> >           + $self->R::Clerk::pay_rate      * $self->drudgery; >> >   } >> > } >> > my $employee = R::Employee->new( >> >     programming_hours => 15, >> >     drudgery          => 25, >> > ); >> > say $employee->paycheck; >> >> >> With 'R::Programmer' and 'R::Clerk' composed on separate > lines, you no >> longer get compositional safety and roles become little more than >> glorified mixins. These were problems that roles/traits were designed >> to fix. This is not an improvement. > > There's no need to actually compose them separately, things work just > fine if you compose them on the same line. I think you may have misread the code. He composed them separately because if he composed them at the same time, he would get a conflict:     Due to a method name conflict in roles 'R::Clerk' and 'R::Programmer',      the method 'pay_rate' must be implemented or excluded by 'R::Employee' at ... Thus, in this instance, he was forced to compose those roles separately (since "exclude" is going to be taken away) and lose compositional safety. >> And I should not have to hardcode the class names into my method >> names. That's a hack that we sometimes fall back on to work around MI >> limitations when you're trying to call an otherwise unreachable method >> and now it's bubbling up into roles? > > How is this meaningfully different? You're already hardcoding the role > names at the point where you consume them. For the same reason that any cutting-and-pasting is a bad idea: our role as programmers is to minimize code duplication as much as possible to ensure that when we do have to change something, we minimize the number of places where said change needs to be made. I would much rather switch the name of the role I'm using at the top of my class and know that things *just work* (again, as was part of the original intent of Smalltalk traits) instead of having to remember to do a search and replace for every place where I've had to hard-code a package name. I could also easily see someone subclassing "Employee" and now having to remember that if they want pay_rate, it's either $self->R::Clerk::pay_rate or $self->R::Programmer::pay_rate . The subclass *shouldn't* have to know the implementation details of Employee to make this work. Piers' solution of using "*programmer_pay_rate = \&R::Programmer::pay_rate is" is ugly, but it's marginally better. However, that's the sort of scaffolding code that roles were (pardon the broken record) designed to handle. The tools to get this right are already in Moose, so I'm really confused about what's going on here. I ask again: what benefit from removing 'alias' and 'exclude' is so strong that it's worth removing a tool that Moose has provided for years? Cheers, Ovid http://www.nntp.perl.org/group/perl.moose/2013/03/msg2610.html Fri, 29 Mar 2013 15:04:43 +0000 Re: Announcement: Moose 2.0800 is released! by Jesse Luehrs On Fri, Mar 29, 2013 at 05:34:50AM -0700, Ovid wrote: > ----- Original Message ----- > > > From: Lars Balker <lars@balker.dk> > > > > As Jesse's earlier example showed, instead of excluding and aliasing, > > just refer to the methods directly within the roles: > > > > use v5.10.0; > > { package R::Programmer; use Moose::Role; sub pay_rate {12} } > > { package R::Clerk;      use Moose::Role; sub pay_rate {10} } > > { package R::Employee;  use Moose; > >   with 'R::Programmer'; > >   with 'R::Clerk'; > >   has [qw/programming_hours drudgery/] => ( is => 'ro' ); > >   sub paycheck { > >       my $self = shift; > >       return $self->R::Programmer::pay_rate * $self->programming_hours > >           + $self->R::Clerk::pay_rate      * $self->drudgery; > >   } > > } > > my $employee = R::Employee->new( > >     programming_hours => 15, > >     drudgery          => 25, > > ); > > say $employee->paycheck; > > > With 'R::Programmer' and 'R::Clerk' composed on separate lines, you no > longer get compositional safety and roles become little more than > glorified mixins. These were problems that roles/traits were designed > to fix. This is not an improvement. There's no need to actually compose them separately, things work just fine if you compose them on the same line. > And I should not have to hardcode the class names into my method > names. That's a hack that we sometimes fall back on to work around MI > limitations when you're trying to call an otherwise unreachable method > and now it's bubbling up into roles? How is this meaningfully different? You're already hardcoding the role names at the point where you consume them. -doy http://www.nntp.perl.org/group/perl.moose/2013/03/msg2609.html Fri, 29 Mar 2013 14:17:21 +0000 Re: Announcement: Moose 2.0800 is released! by Piers Cawley On 29 March 2013 09:13, Ovid <curtis_ovid_poe@yahoo.com> wrote: > In short: > > 1. Allowing a role to silently override a consumed role's methods moves Perl roles even further away from Smalltalk-style traits and its associative and commutative guarantees. Given that, unless you implement 'pay_rate' in your consuming role, then 'with qw(R::Programmer R::Clerk)' is going to blow up because you haven't resolved the conflict I'm not entirely sure your claim has any validity here. > > Regarding plans to remove 'alias' and 'excludes': > > 2. Intending to remove the aliasing and excluding composition tools removes tools that allow finer control over how you consume your objects. At the point you compose the two conflicting roles (using with qw(R::Programmer R::Clerk) you are required to resolve the conflict and, at that point, you know the fully qualified names of the methods that are in conflict, you've got all the fine control you could desire. Yes, it's going to look ugly, what with the long names and all, but if that's _really_ a problem and excludes/alias have gone away, you still have possibilities like this open to you: with qw(R::Programmer R::Clerk); *programmer_rate = *R::Programmer::pay_rate; *clerk_rate = *R::Clerk::pay_rate; sub pay_rate { my $self = shift; confess "Liskov Substitution Principle violation in progress" or return ( $self->programmer_rate * $self->programmer_hours + $self->clerk_rate * $self->clerk_hours ) / $self->total_hours; } And yes, it's horribly ugly, but your modelling here is horribly ugly too and ugly things should be ugly. And what it buys me in exchange is Roles that don't surprise me all the bloody time by not doing the the Right Thing. The new system for resolution boils down to a pretty simple mechanism: When composing one more more roles into a target package then, for any given $method of those roles we apply the following logic: $method_choice = $target->can($method) or do { @possibilities = map { $_->can($method) || () } @roles; confess "Bad programmer, no cookie!" unless @possibilities == 1; $possibilities[0]; } Straightforward, consistent, predictable. What's not to like? This means that, in the 90% case of two roles conflicting (we want to choose the methods from one of them) we can write: use (Role::Winner); use (Role::RunnerUp); And in the ickier cases, we can still control how things get resolved, but the code will be icky. Because that's okay, because the sooner our bad modelling forces us to write icky code, the sooner we can realise that it's bad modelling and fix the model. > 3. Removing certain use cases for role composition and forcing developers to fall back on delegation is a significant performance hit. Not sure I'm understanding which use case has gone away. http://www.nntp.perl.org/group/perl.moose/2013/03/msg2608.html Fri, 29 Mar 2013 13:25:38 +0000 Re: Announcement: Moose 2.0800 is released! by Ovid ----- Original Message ----- > From: Lars Balker <lars@balker.dk> > > As Jesse's earlier example showed, instead of excluding and aliasing, > just refer to the methods directly within the roles: > > use v5.10.0; > { package R::Programmer; use Moose::Role; sub pay_rate {12} } > { package R::Clerk;      use Moose::Role; sub pay_rate {10} } > { package R::Employee;  use Moose; >   with 'R::Programmer'; >   with 'R::Clerk'; >   has [qw/programming_hours drudgery/] => ( is => 'ro' ); >   sub paycheck { >       my $self = shift; >       return $self->R::Programmer::pay_rate * $self->programming_hours >           + $self->R::Clerk::pay_rate      * $self->drudgery; >   } > } > my $employee = R::Employee->new( >     programming_hours => 15, >     drudgery          => 25, > ); > say $employee->paycheck; With 'R::Programmer' and 'R::Clerk' composed on separate lines, you no longer get compositional safety and roles become little more than glorified mixins. These were problems that roles/traits were designed to fix. This is not an improvement. And I should not have to hardcode the class names into my method names. That's a hack that we sometimes fall back on to work around MI limitations when you're trying to call an otherwise unreachable method and now it's bubbling up into roles? "alias" and "excludes" are simple, clean ways of dealing with role composition issues that arise. They are a code smell. A code smell doesn't mean that there's defintiely a bug; it means that there may be an issue and it's worth looking at further. When another team at work writes a role that's useful in my code, I would like to simply be able to use that role and not jump through hoops because other developers have decided that alias and exclude are always bad and therefore I can't have it. Rather than showing me hacks to work around the plans to deprecate these features, can someone at least make a strong argument why these features are so bad that they need to be eliminated? Preferably with code examples? Heck, even if the explanation is "these features are valuable but caused many bugs inside Moose", I could at least see a rationale for this removal. Instead, this sounds dangerously close to the old problem of "we need a word processor that only has the 10% of features that people actually use", but ignores the fact that different people use different subsets of behavior. Regards, Ovid http://www.nntp.perl.org/group/perl.moose/2013/03/msg2607.html Fri, 29 Mar 2013 12:35:01 +0000 Re: Announcement: Moose 2.0800 is released! by Lars Balker On Fri, Mar 29, 2013 at 10:13 AM, Ovid <curtis_ovid_poe@yahoo.com> wrote: > { package R::Programmer; use Moose::Role; sub pay_rate {12} } > { package R::Clerk; use Moose::Role; sub pay_rate {10} } > { package R::Employee; use Moose; > with 'R::Programmer' => { > # this is why I want a "rename" property here > exclude => 'pay_rate', > alias => { pay_rate => 'programmer_pay_rate' } > }, > 'R::Clerk' => { > exclude => 'pay_rate', > alias => { pay_rate => 'clerk_pay_rate' } > }; > has [qw/hours programming_hours drudgery/] => ( is => 'ro' ); > sub pay_rate {8} # ugly hack for quick example. Oops > > sub paycheck { > my $self = shift; > return $self->programmer_pay_rate * $self->programming_hours > + $self->clerk_pay_rate * $self->drudgery; > } > } > my $employee = R::Employee->new( > programming_hours => 15, > drudgery => 25, > ); > say $employee->paycheck; As Jesse's earlier example showed, instead of excluding and aliasing, just refer to the methods directly within the roles: use v5.10.0; { package R::Programmer; use Moose::Role; sub pay_rate {12} } { package R::Clerk; use Moose::Role; sub pay_rate {10} } { package R::Employee; use Moose; with 'R::Programmer'; with 'R::Clerk'; has [qw/programming_hours drudgery/] => ( is => 'ro' ); sub paycheck { my $self = shift; return $self->R::Programmer::pay_rate * $self->programming_hours + $self->R::Clerk::pay_rate * $self->drudgery; } } my $employee = R::Employee->new( programming_hours => 15, drudgery => 25, ); say $employee->paycheck; -- Lars Balker Consult::Perl http://www.nntp.perl.org/group/perl.moose/2013/03/msg2606.html Fri, 29 Mar 2013 11:56:40 +0000 Re: Announcement: Moose 2.0800 is released! by Ovid > From: Jesse Luehrs <doy@tozt.net> >No, overriding is a perfectly valid way to resolve conflicts, and always >has been. alias and excludes are only important to fix cases where this >isn't possible, and this change should remove the last of those. So I can avoid spamming the list regarding things already hashed out, can you point me to the prior discussions where this change was decided? I'm hoping to better understand other's thinking on this (I've discussed this with mst, but I don't think it would be fair to assume that his opinions apply to everyone else). My concern about removing "alias" and "excludes" stems in part from how I appear to have a slightly different philosophy about OO programming. I view objects as experts about solving a given problem, but the underlying object is composed of "legos" of roles. Need some new behavior? I rummage around in my toy box looking for the legos to snap onto my existing object. Viewing each object as a collection of well-defined behaviors rather than "how can I squeeze this into a tree or graph hierarchy" lets me just get things done, though I realize I may be in the minority here. For example, in my first programming job, I worked several hours a week as a programmer and the rest of the week I was a glorified clerk. I was (illegally) paid at different rates for each job. So the "employee" sometimes behaves as a clerk and sometimes behaves as a programmer. Calculating my pay with roles is fairly straightforward (funky formatting to make it easier to fit in the email):     { package R::Programmer; use Moose::Role; sub pay_rate {12} }                                                                                   { package R::Clerk;      use Moose::Role; sub pay_rate {10} }     { package R::Employee;   use Moose;         with 'R::Programmer' => {             # this is why I want a "rename" property here             exclude => 'pay_rate',             alias   => { pay_rate => 'programmer_pay_rate' }           },           'R::Clerk' => {             exclude => 'pay_rate',             alias   => { pay_rate => 'clerk_pay_rate' }           };         has [qw/hours programming_hours drudgery/] => ( is => 'ro' );         sub pay_rate {8} # ugly hack for quick example. Oops         sub paycheck {             my $self = shift;             return $self->programmer_pay_rate * $self->programming_hours                  + $self->clerk_pay_rate      * $self->drudgery;                                                                                        }     }     my $employee = R::Employee->new(         programming_hours => 15,         drudgery          => 25,     );     say $employee->paycheck; (yes, there's some cruft in this quickly hacked together example and it's deliberately kept simple (e.g., pay_rate) to focus on the role composition issue) How do I do that without roles? I'm not going to fall back on MI because that introduces the very problems that roles were trying to solve! Thus, delegation seems to be the trick (if I'm creating a straw man argument here, my apologies. Please correct me). Here's the first pass at that:     {   package R::Paycheck; use Moose::Role;                                                                                                           requires 'pay_rate';         has [qw/hours_worked/] => ( is => 'ro' );         sub paycheck {             my $self = shift;             return $self->hours_worked * $self->pay_rate;         }     }     { package C::Programmer; use Moose; with 'R::Paycheck'; sub pay_rate { 12 } }     { package C::Clerk;      use Moose; with 'R::Paycheck'; sub pay_rate { 10 } }     { package C::Employee; use Moose;         has [qw/programming_hours drudgery/] => ( is => 'ro' );         has 'programmer' => ( is => 'ro', lazy => 1, builder => '_build_programmer' );         has 'clerk'      => ( is => 'ro', lazy => 1, builder => '_build_clerk' );         sub _build_programmer {             my $self = shift;             C::Programmer->new( hours_worked => $self->programming_hours );         }         sub _build_clerk {             my $self = shift;             C::Clerk->new( hours_worked => $self->drudgery );         }         sub paycheck {             my $self = shift;             return $self->programmer->paycheck + $self->clerk->paycheck;         }     } In some respects it's cleaner, but in other respects, it's not. For example, many of my roles are things that shouldn't necessarily be instantiated on their own (Serializable), but if I'm forced to use delegation for composition because I don't have exclusion and aliasing, then sometimes I'm going to have to fall back on the old hack of creating classes to add some behavior, even if the "class" shouldn't really be a class. (See also: http://steve-yegge.blogspot.fr/2006/03/execution-in-kingdom-of-nouns.html). Further, while I realize my "lego" approach to building classes isn't to everyone's tastes, it does tend to shake out bugs in role implementations very quickly. For example, I've had to give up on Moo because its roles are so buggy (https://rt.cpan.org/Public/Bug/Display.html?id=82711). So unless there's a really concrete, demonstrable problem with aliasing and excluding, I'm very concerned about taking away these tools that have been in my toolbox for many years. Finally, we can consider performance. When a role's methods are flattened into my class, they're going to be faster than delegation.      use Benchmark;                                                                                                                                  my %args = (         programming_hours => 15,         drudgery          => 25,     );     timethese(         100000,         {   roles   => sub { R::Employee->new(%args)->paycheck },             classes => sub { C::Employee->new(%args)->paycheck },         }     ); In this example, we see that roles are more than twice as fast as delegation:     Benchmark: timing 100000 iterations of classes, roles...        classes: 14 wallclock secs (14.20 usr +  0.00 sys = 14.20 CPU) @ 7042.25/s (n=100000)          roles:  6 wallclock secs ( 5.63 usr +  0.00 sys =  5.63 CPU) @ 17761.99/s (n=100000) As it turns out, object creation is very expensive, so if we skip that part and just call the salary method (and we'll bump this up to one million iterations):     use Benchmark;     my %args = (         programming_hours => 15,         drudgery          => 25,     );     my $roles   = R::Employee->new(%args);     my $classes = C::Employee->new(%args);     timethese(         1000000,                                                                                                                                        {   roles   => sub { $roles->paycheck },             classes => sub { $classes->paycheck },         }     );     Benchmark: timing 1000000 iterations of classes, roles...        classes:  3 wallclock secs ( 2.88 usr +  0.00 sys =  2.88 CPU) @ 347222.22/s (n=1000000)          roles:  0 wallclock secs ( 1.28 usr +  0.00 sys =  1.28 CPU) @ 781250.00/s (n=1000000) We still see the roles as slightly twice as fast as delegation. In short: 1. Allowing a role to silently override a consumed role's methods moves Perl roles even further away from Smalltalk-style traits and its associative and commutative guarantees. Regarding plans to remove 'alias' and 'excludes': 2. Intending to remove the aliasing and excluding composition tools removes tools that allow finer control over how you consume your objects. 3. Removing certain use cases for role composition and forcing developers to fall back on delegation is a significant performance hit. Cheers, Ovid-- Twitter - http://twitter.com/OvidPerl/ Buy my book - http://bit.ly/beginning_perl Buy my other book - http://www.oreilly.com/catalog/perlhks/ Live and work overseas - http://www.overseas-exile.com/ http://www.nntp.perl.org/group/perl.moose/2013/03/msg2605.html Fri, 29 Mar 2013 09:13:17 +0000 Re: Moose 2.0801 coming up soon by Karen Etheridge On Thu, Mar 28, 2013 at 02:16:59PM -0700, Karen Etheridge wrote: > ...a 2.0801 fix will be coming up shortly (by end of day, UTC-0700) -- > involving either a fix, or a reversion of this change. Now available at a mirror near you: http://metacpan.org/release/ETHER/Moose-2.0801 sorry again! -- you forth love if honk then . . . . . Karen Etheridge, karen@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://www.nntp.perl.org/group/perl.moose/2013/03/msg2604.html Thu, 28 Mar 2013 22:04:16 +0000 Moose 2.0801 coming up soon by Karen Etheridge Unfortunately, a few issues in some Moose extensions have been found with the latest release, and since **** this breaks some Catalyst installations **** ...a 2.0801 fix will be coming up shortly (by end of day, UTC-0700) -- involving either a fix, or a reversion of this change. (FWIW, it doesn't seem to be caused by the role application change being discussed.) I am very sorry for the inconvenience! -- The only person who ever got his work done by Friday was Robinson Crusoe. . . . . . Karen Etheridge, karen@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++ http://www.nntp.perl.org/group/perl.moose/2013/03/msg2603.html Thu, 28 Mar 2013 21:17:22 +0000 Re: Announcement: Moose 2.0800 is released! by Piers Cawley On 28 March 2013 17:45, Jesse Luehrs <doy@tozt.net> wrote: > On Thu, Mar 28, 2013 at 05:42:18PM +0000, Piers Cawley wrote: >> On 28 March 2013 17:36, Piers Cawley <pdcawley@bofh.org.uk> wrote: >> > On 28 March 2013 16:41, Jesse Luehrs <doy@tozt.net> wrote: >> >> On Thu, Mar 28, 2013 at 09:20:55AM -0700, Ovid wrote: >> >>> Ouch! You're right. My apologies for the confusion. The examples should be this: >> >>> >> >>> use 5.01000; >> >>> { package a; use Moose::Role; sub result { 'a' } } >> >>> { package b; use Moose::Role; } >> >>> { package c; use Moose::Role; with qw(a b); sub result { 'c' } } >> >>> { package d; use Moose::Role; with qw(c); } >> >>> { >> >>> package Consumer; use Moose; >> >>> with 'd'; >> >>> } >> >>> say Consumer->new->result; >> >>> >> >>> Versus: >> >>> >> >>> use 5.01000; >> >>> { package a; use Moose::Role; with qw(b c); sub result { 'a' } } >> >>> { package b; use Moose::Role; } >> >>> { package c; use Moose::Role; sub result { 'c' } } >> >>> { package d; use Moose::Role; with qw(a); } >> >>> { >> >>> package Consumer; use Moose; >> >>> with 'd'; >> >>> } >> >>> say Consumer->new->result; >> >>> >> >>> Only the order of role consumption is changed, but the behavior is now different. >> >> >> >> I can't really agree here that "only the order of role consumption is >> >> changed". I certainly wouldn't have the expectation that those two code >> >> snippets would necessarily produce the same result. The reason for this >> >> change is to bring role composition in roles into line with how role >> >> composition in classes works. For instance, here: >> >> >> >> package a; use Moose::Role; sub result { 'a' } >> >> package b; use Moose; sub result { 'b' } >> >> >> >> This has always worked without error. On the other hand, this: >> >> >> >> package a; use Moose::Role; sub result { 'a' } >> >> package b; use Moose::Role; sub result { 'b' } >> >> >> >> has historically been a conflict error, and one that has bit me (and >> >> several other people) on several occasions. I have never meant anything >> >> other than the behavior that happens in the class case, so I don't see >> >> why extending that behavior to the role case is a problem. (Or is it >> >> your opinion that the first snippet there should also be a conflict?) >> >> >> >> In general, I can't really understand why the behavior for roles and >> >> classes should be different in this sense. A role consuming another role >> >> is a different operation from role summation, and one that I think >> >> should behave more similarly to a class consuming a role. Note that this >> >> is still a conflict: >> >> >> >> { package a; use Moose::Role; sub result { 'a' } } >> >> { package b; use Moose::Role; } >> >> { package c; use Moose::Role; sub result { 'c' } } >> >> { package d; use Moose::Role; with qw(a b c); } >> >> >> >> The other benefit here is that with this change, alias and excludes >> >> become completely unnecessary, and can hopefully be deprecated. >> > >> > Whoah! What? So when I want to compose, say a and b and write my own >> > 'result' which will combine a's result and b's result, what am I >> > supposed to do? >> > >> > I'd always been under the impression that when I do: >> > >> > with qw(a b);\ >> > >> > I'm expressing the expectation that there are no conflicts between >> > those two roles and I want an (ideally compile time) error if they do >> > conflict, and I can get in and fix it through judicious use of >> > excludes (and possibly an alias or two). >> > >> > If I want the order of composition to matter, then I can do >> > >> > with 'a'; >> > with 'b'; >> > >> > For the life of me I can't see how this change can be called a good idea. >> > >> >> If what you're after here is a way to disallow all forms of silent >> >> method overriding, I think this is better done in an extension (since it >> >> would have to catch conflicts in inheritance situations as well anyway). >> > >> > That's certainly not what I'm after. But I do want to retain the >> > difference between 'with qw(a b)' and 'with q(a); with q(b);' thank >> > you very much. >> > >> > Who cooked up this idea? >> >> To clarify: I'm all for having this: >> >> package a; use Moose::Role; sub result { 'a' }; >> package b; use Moose::Role; with 'a'; sub result { 'b' } >> >> work without throwing any warnings, but if that comes at the expense of: >> >> package a; use Moose::Role; sub result { 'a' }; >> package b; use Moose::Role; sub result { 'b' }; >> package c; use Moose; with qw(a b); > > No, this is still a conflict. Role composition and role summation are > two separate processes. Ah. Fair enough. Misunderstanding Ovid's original code sample. http://www.nntp.perl.org/group/perl.moose/2013/03/msg2602.html Thu, 28 Mar 2013 17:51:56 +0000