perl.moose http://www.nntp.perl.org/group/perl.moose/ ... Copyright 1998-2016 perl.org Wed, 31 Aug 2016 22:11:56 +0000 ask@perl.org nested traits problem with moose 2.1005->2.1804 by Toby Blake Hi,<br/><br/>We have a bit of code which has broken between 2.1005 and 2.1804 - it<br/>was originally written somewhere around 0.85 and I don&#39;t think has<br/>really changed much since then.<br/><br/>The code involves a trait which consumes another trait, and this seems<br/>to be what&#39;s causing the problem. Hopefully some (cut-down) code will<br/>explain this...<br/><br/><br/>package Test::Meta::Role::Trait::CoreObject;<br/><br/>use Moose::Role;<br/><br/>has primaryAttribute =&gt; (<br/> is =&gt; &#39;rw&#39;,<br/> isa =&gt; &#39;Str&#39;);<br/><br/>Moose::Exporter-&gt;setup_import_methods(<br/> with_caller =&gt; [ &#39;primaryKey&#39; ],<br/> also =&gt; &#39;Moose::Role&#39;,<br/>);<br/><br/>sub primaryKey {<br/> my $meta = shift;<br/> $meta = Moose::Meta::Role-&gt;initialize($meta) if !ref($meta);<br/><br/> return $meta-&gt;primaryAttribute(@_);<br/>}<br/><br/>no Moose::Role;<br/><br/>package Moose::Meta::Role::Custom::Trait::CoreObject;<br/>sub register_implementation<br/>{&#39;Test::Meta::Role::Trait::CoreObject&#39;};<br/><br/>1;<br/><br/><br/>package Test::Meta::Role::Trait::LDAPObject;<br/><br/>use Moose::Role;<br/><br/>with &#39;Test::Meta::Role::Trait::CoreObject&#39;;<br/><br/>has oid =&gt; (<br/> is =&gt; &#39;rw&#39;,<br/> isa =&gt;&#39;Str&#39;,<br/>);<br/><br/>Moose::Exporter-&gt;setup_import_methods(<br/> with_caller =&gt; [ &#39;oid&#39;, &#39;primaryKey&#39; ],<br/> also =&gt; &#39;Moose::Role&#39;,<br/>);<br/><br/>sub oid {<br/> my $meta = Moose::Meta::Role-&gt;initialize(shift);<br/> $meta-&gt;oid(shift);<br/>}<br/><br/>no Moose::Role;<br/><br/>package Moose::Meta::Role::Custom::Trait::LDAPObject;<br/>sub register_implementation<br/> {&#39;Test::Meta::Role::Trait::LDAPObject&#39;};<br/><br/>1;<br/><br/><br/>package Test::TestRole;<br/>use Test::Meta::Role::Trait::LDAPObject;<br/>se Moose::Role -traits =&gt; &#39;LDAPObject&#39;;<br/><br/>oid &#39;1.3.6.1.4.1.4247.1.747.99.23&#39;;<br/><br/>no Moose::Role;<br/>1;<br/><br/><br/>$ perl -Ilib -MTest::TestRole<br/>String found where operator expected at lib/Test/TestRole.pm line 5, near &quot;oid &#39;1.3.6.1.4.1.4247.1.747.99.23&#39;&quot;<br/> (Do you need to predeclare oid?)<br/>syntax error at lib/Test/TestRole.pm line 5, near &quot;oid &#39;1.3.6.1.4.1.4247.1.747.99.23&#39;&quot;<br/>BEGIN not safe after errors--compilation aborted at lib/Test/TestRole.pm line 7.<br/>Compilation failed in require.<br/>BEGIN failed--compilation aborted.<br/>$<br/><br/><br/>The LDAPObject trait works fine when it doesn&#39;t consume the CoreObject<br/>trait (and I remove primaryKey from setup_import_methods), so I<br/>suspect we&#39;re using Moose::Exporter incorrectly, but I&#39;m not too<br/>familiar with this side of moose meta, in that I don&#39;t want to try and<br/>jsut hack my way around it. Any assistance would be greatly<br/>appreciated.<br/><br/><br/>Cheers<br/>Toby Blake<br/>School of Informatics<br/>University of Edinburgh<br/><br/>-- <br/>The University of Edinburgh is a charitable body, registered in<br/>Scotland, with registration number SC005336.<br/><br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2975.html Fri, 12 Aug 2016 09:54:14 +0000 Re: Why to use Moose roles ever? by Thomas Klausner Hi!<br/><br/>&gt; Are there any real situations where roles are better than base classes?<br/>&gt; With examples, please.<br/><br/>I think MooseX::Storage is a nice example: You have some class (with <br/>whatever interitance tree), apply a generic role from CPAN, and bam! you <br/>can serialize your objects. Yes, you could achieve the same effect using <br/>plain old inheritance, but the you&#39;d probably have to use multiple <br/>inheritance, which leads to all kinds of chaos (which of course can be <br/>managed, but why, when roles provide a cleaner solution).<br/><br/>https://metacpan.org/pod/MooseX::Storage<br/><br/>Greetings,<br/>domm<br/><br/>-- <br/>#!/usr/bin/perl http://domm.plix.at<br/>for(ref bless{},just&#39;another&#39;perl&#39;hacker){s-:+-$&quot;-g&amp;&amp;print$_.$/}<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2974.html Thu, 11 Aug 2016 08:48:17 +0000 Re: Why to use Moose roles ever? by Kent Fredric On 11 August 2016 at 17:31, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt;&gt; &quot;around&quot; retrieves MyClass::foo ( which was MyRole::foo ) and<br/>&gt;&gt; wraps/overrides it.<br/>&gt;<br/>&gt;<br/>&gt; Wraps yes, override ... not in my book, but I appreciate where you&#39;re coming<br/>&gt; from.<br/><br/>Right. You should be able to use normal override mechanics, just<br/>wrapping is more practical for some concerns.<br/><br/>If you can give examples of a case where you &quot;can&#39;t override&quot; that<br/>seems like it would be helpful.<br/><br/>&gt; Can you point to &quot;interface X&quot;? In my (admittedly limited) experiments with<br/>&gt; Moose::Role an &quot;interface&quot; doesn&#39;t exist, conceptually or practically. I<br/>&gt; was hoping to implement Interface roles, and have Implementation roles which<br/>&gt; provide behaviours (my final trade-off experiment was to explore it via<br/>&gt; inner-augment), and have them consumed by Classes in a sane and safe way,<br/>&gt; but I couldn&#39;t find one e.g. not being able to have an Implementation role<br/>&gt; depend on an Interface role, and have those indirect Interface dependencies<br/>&gt; automatically consumed by a Class<br/><br/>Roles are basically usable as 2 things. But yes, there&#39;s no formal<br/>&quot;interface&quot;, simply &quot;roles that require methods or provide them&quot;.<br/><br/>Thus, a role enforces the method is &quot;there&quot; in some way, either by<br/>providing it itself, or using the &quot;requires&quot; technique.<br/><br/>The name of the role is the name of the interface it provides, because<br/>every thing that consume a role can be checked via &quot;does&quot;<br/><br/>Some roles may opt to provide no subs of their own, and are merely a<br/>collection of &quot;requires&quot; statements that require the class that<br/>composes them to define it.<br/><br/>So, by consuming a role of either type, you &quot;claim&quot; that you support<br/>the API as documented in that role. ( But the implementation as to how<br/>that claim is satisfied can vary )<br/><br/>&gt; But I think we&#39;re straying far from the OP - I don&#39;t think we&#39;ve seen a<br/>&gt; concrete example that helps him. I suspect he&#39;s arrived where many of us<br/>&gt; have, where no amount of Moose design-rationale or workarounds seem<br/>&gt; appropriate in solving the types of problems that we&#39;re trying to solve.<br/><br/>Sure, and there are problems here, if you use too many roles you&#39;ll<br/>hurt yourself, if you use too much inheritance you&#39;ll hurt yourself.<br/><br/>Some work flows make sense, others don&#39;t.<br/><br/>But as I mentioned earlier, I&#39;m much more leaning towards attribute<br/>based composition where possible with method delegation. Deep<br/>hierarchies will make your life hard regardless of how you do it.<br/><br/>So the best choice is not to.<br/><br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2973.html Thu, 11 Aug 2016 08:21:18 +0000 Re: Why to use Moose roles ever? by Niall Young On Thu, 11 Aug 2016, Kent Fredric wrote:<br/><br/>&gt; On 11 August 2016 at 16:36, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt;&gt; On Thu, 11 Aug 2016, Kent Fredric wrote:<br/>&gt;&gt;<br/>&gt;&gt;&gt; On 11 August 2016 at 15:43, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Not sure how your example applies here Karen, there is no foo() declared<br/>&gt;&gt;&gt;&gt; in<br/>&gt;&gt;&gt;&gt; MyClass only a foo method modifier, and MyRole&#39;s foo() doesn&#39;t appear to<br/>&gt;&gt;&gt;&gt; be<br/>&gt;&gt;&gt;&gt; executed from your output?<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; In the example she gave, the point was not to call MyRole&#39;s foo, only<br/>&gt;&gt;&gt; to replace it. ( Because Roles prohibit replacement by default, its a<br/>&gt;&gt;&gt; conflict that must be manually resolved )<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; The OP&#39;s goal was to override MyClass&#39;s foo, not MyRole&#39;s foo.<br/>&gt;<br/>&gt; OP:<br/>&gt;&gt; Moose roles have some limitations, such as inability to override a<br/>&gt;&gt; method in a class which &quot;with&quot;es the role.<br/>&gt;<br/>&gt; Overriding a method in a parent class that composes a role is<br/>&gt; identical in practice<br/>&gt; to overriding a method in a composed role.<br/><br/>I&#39;m not trying to be pedantic, but overriding a method != utilising a method modifier to achieve a similar/same outcome. The syntax used to achieve that outcome is important, to me it&#39;s actually more important than having the capability to achieve approximately the same outcome, if that means utilising a workaround and/or inconsistent syntax (cognitive overhead, keeping in mind all of the constraints/quirks etc.).<br/><br/>&gt; &quot;around&quot; retrieves MyClass::foo ( which was MyRole::foo ) and<br/>&gt; wraps/overrides it.<br/><br/>Wraps yes, override ... not in my book, but I appreciate where you&#39;re coming from.<br/><br/>&gt;&gt; Moose cleans up Classes tremendously, which by itself is a pretty huge win<br/>&gt;&gt; (not to mention access to the MOP at runtime etc.) but Roles .. like the OP<br/>&gt;&gt; I&#39;m still struggling to find a use-case which lives up to their potential.<br/>&gt;&gt; I really, really want to use them, but they come with their own issues, or<br/>&gt;&gt; costs which seem to negate or outweigh their benefits. That&#39;s not a<br/>&gt;&gt; criticism btw, just an observation.<br/>&gt;<br/>&gt; But this is good, really, you shouldn&#39;t be &quot;trying to find a use for<br/>&gt; it&quot;, that&#39;s sort of coding-by-patterns and it never ends well.<br/><br/>Oh you misunderstand, I have many uses for them e.g. all of the benefits of Traits and composing behaviours (safely and predictably via commutative and associative safety) over deep or multiple inheritance. But every single attempt to utilise them for that purpose has left me disappointed, and I&#39;ve been unable to justify the cost that they introduce.<br/><br/>&gt; Because &quot;with&quot; not only indicates &quot;Please compose X&quot; , but advertises<br/>&gt; &quot;I conform to interface X&quot;<br/><br/>Can you point to &quot;interface X&quot;? In my (admittedly limited) experiments with Moose::Role an &quot;interface&quot; doesn&#39;t exist, conceptually or practically. I was hoping to implement Interface roles, and have Implementation roles which provide behaviours (my final trade-off experiment was to explore it via inner-augment), and have them consumed by Classes in a sane and safe way, but I couldn&#39;t find one e.g. not being able to have an Implementation role depend on an Interface role, and have those indirect Interface dependencies automatically consumed by a Class<br/><br/>But I think we&#39;re straying far from the OP - I don&#39;t think we&#39;ve seen a concrete example that helps him. I suspect he&#39;s arrived where many of us have, where no amount of Moose design-rationale or workarounds seem appropriate in solving the types of problems that we&#39;re trying to solve.<br/><br/>--<br/>Niall Young<br/>niall@iinet.net.au<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2972.html Thu, 11 Aug 2016 05:31:35 +0000 Re: Why to use Moose roles ever? by Kent Fredric On 11 August 2016 at 16:36, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt; On Thu, 11 Aug 2016, Kent Fredric wrote:<br/>&gt;<br/>&gt;&gt; On 11 August 2016 at 15:43, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Not sure how your example applies here Karen, there is no foo() declared<br/>&gt;&gt;&gt; in<br/>&gt;&gt;&gt; MyClass only a foo method modifier, and MyRole&#39;s foo() doesn&#39;t appear to<br/>&gt;&gt;&gt; be<br/>&gt;&gt;&gt; executed from your output?<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; In the example she gave, the point was not to call MyRole&#39;s foo, only<br/>&gt;&gt; to replace it. ( Because Roles prohibit replacement by default, its a<br/>&gt;&gt; conflict that must be manually resolved )<br/>&gt;<br/>&gt;<br/>&gt; The OP&#39;s goal was to override MyClass&#39;s foo, not MyRole&#39;s foo.<br/><br/>OP:<br/>&gt; Moose roles have some limitations, such as inability to override a<br/>&gt; method in a class which &quot;with&quot;es the role.<br/><br/>Overriding a method in a parent class that composes a role is<br/>identical in practice<br/>to overriding a method in a composed role.<br/><br/><br/><br/>{ package MyRole;<br/> use Moose::Role;<br/> sub foo { return &quot;In role&quot; }<br/>}<br/>{ package MyClass;<br/> use Moose;<br/> with &quot;MyRole&quot;;<br/>}<br/>{<br/> package MyOtherClass;<br/> use Moose;<br/> extends &quot;MyClass&quot;;<br/> around &quot;foo&quot; =&gt; sub { ... }<br/>}<br/><br/>Done.<br/><br/>MyClass composes MyRole so &quot;MyRole::foo&quot; is now &quot;MyClass::foo&quot;;<br/><br/>&quot;around&quot; retrieves MyClass::foo ( which was MyRole::foo ) and<br/>wraps/overrides it.<br/><br/><br/>&gt;<br/>&gt;&gt; If one wants to call MyRole::foo in the new MyClass::foo, this is done:<br/>&gt;&gt; around foo =&gt; sub {<br/>&gt;&gt; my ( $orig, $self, @args );<br/>&gt;&gt; return join q[, ], &#39;I came from the class&#39;, $self-&gt;$orig( @args );<br/>&gt;<br/>&gt;<br/>&gt; It seems cumbersome, and makes Classes aware of and dependent on the<br/>&gt; existence of Role(s).<br/>&gt;<br/>&gt; Like the OP I struggled to come up with a good way to take advantage of<br/>&gt; Roles, as nice as they are in principle there are some fundamental<br/>&gt; constraints which make applying them (and enjoying their inherent benefits,<br/>&gt; or start approaching the benefits of Traits) problematic.<br/>&gt;<br/>&gt; Moose cleans up Classes tremendously, which by itself is a pretty huge win<br/>&gt; (not to mention access to the MOP at runtime etc.) but Roles .. like the OP<br/>&gt; I&#39;m still struggling to find a use-case which lives up to their potential.<br/>&gt; I really, really want to use them, but they come with their own issues, or<br/>&gt; costs which seem to negate or outweigh their benefits. That&#39;s not a<br/>&gt; criticism btw, just an observation.<br/><br/>But this is good, really, you shouldn&#39;t be &quot;trying to find a use for<br/>it&quot;, that&#39;s sort of coding-by-patterns and it never ends well.<br/><br/>You should just know what its for, so when a situation arises you need<br/>it, its there.<br/><br/>They&#39;re usually the cases where you *dont* want the originator of the<br/>sub to turn up in @ISA<br/><br/>And they&#39;re usually similar cases to where you might reach for<br/>Import/Export if you&#39;re writing functional interfaces.<br/><br/>( After all, &quot;Roles&quot; are basically &quot;Imports, but methods&quot; with a lot<br/>of conveniences on top )<br/><br/>For instance, perhaps you want all your classes to have a &quot;-&gt;dump&quot;<br/>method for debugging purposes, where a basic implementation can be<br/>shared, and the definition can be extended on a class-by-class basis<br/>to give better results where needed.<br/><br/>Making every class in your project inherit a &quot;Debugger&quot; class is just<br/>going to create a horrible mess in the inheritance chains.<br/><br/>Writing that method from scratch in every package is horrible, and you<br/>have no tools to identify which packages have not just a dump method,<br/>but a dump method that conforms to the API you expect it to ( ie: 3rd<br/>party modules may have their own dump methods that might turn up in<br/>places that act differently )<br/><br/>Here, you can just create a Debugger role , and apply it to all your<br/>packages via &quot;WIth&quot;, and then &quot;around dump =&gt; &quot; in places you need to<br/>augment the results.<br/><br/>Then when comes time to consume it, you can just check &quot;hey, this<br/>class is one of the ones that does this thing the way I expect&quot; by<br/>asking $object-&gt;DOES(&quot;My::Debugger&quot;)<br/><br/>and then when that returns true, you know that you can call<br/>$object-&gt;dump and have it behave the way you expect, mostly.<br/><br/>Because &quot;with&quot; not only indicates &quot;Please compose X&quot; , but advertises<br/>&quot;I conform to interface X&quot;<br/><br/>That advertisement can of course be false still, but its more reliable<br/>than a blind $object-&gt;can(&#39;dump&#39;) # good enough?<br/><br/>You never know, one of those might be &quot;trigger coredump and exit&quot; ;)<br/><br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2971.html Thu, 11 Aug 2016 04:54:48 +0000 Re: Why to use Moose roles ever? by Niall Young On Thu, 11 Aug 2016, Kent Fredric wrote:<br/><br/>&gt; On 11 August 2016 at 15:43, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt;&gt; Not sure how your example applies here Karen, there is no foo() declared in<br/>&gt;&gt; MyClass only a foo method modifier, and MyRole&#39;s foo() doesn&#39;t appear to be<br/>&gt;&gt; executed from your output?<br/>&gt;<br/>&gt; In the example she gave, the point was not to call MyRole&#39;s foo, only<br/>&gt; to replace it. ( Because Roles prohibit replacement by default, its a<br/>&gt; conflict that must be manually resolved )<br/><br/>The OP&#39;s goal was to override MyClass&#39;s foo, not MyRole&#39;s foo.<br/><br/>&gt; If one wants to call MyRole::foo in the new MyClass::foo, this is done:<br/>&gt; around foo =&gt; sub {<br/>&gt; my ( $orig, $self, @args );<br/>&gt; return join q[, ], &#39;I came from the class&#39;, $self-&gt;$orig( @args );<br/><br/>It seems cumbersome, and makes Classes aware of and dependent on the existence of Role(s).<br/><br/>Like the OP I struggled to come up with a good way to take advantage of Roles, as nice as they are in principle there are some fundamental constraints which make applying them (and enjoying their inherent benefits, or start approaching the benefits of Traits) problematic.<br/><br/>Moose cleans up Classes tremendously, which by itself is a pretty huge win (not to mention access to the MOP at runtime etc.) but Roles .. like the OP I&#39;m still struggling to find a use-case which lives up to their potential. I really, really want to use them, but they come with their own issues, or costs which seem to negate or outweigh their benefits. That&#39;s not a criticism btw, just an observation.<br/><br/>--<br/>Niall Young<br/>niall@iinet.net.au<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2970.html Thu, 11 Aug 2016 04:37:10 +0000 Re: Why to use Moose roles ever? by Kent Fredric On 11 August 2016 at 16:15, Kent Fredric &lt;kentfredric@gmail.com&gt; wrote:<br/>&gt; my ( $orig, $self, @args );<br/><br/><br/><br/>Bah.<br/><br/> my ( $orig, $self, @args ) = @_;<br/><br/>I make that mistake too often.<br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2969.html Thu, 11 Aug 2016 04:16:47 +0000 Re: Why to use Moose roles ever? by Kent Fredric On 11 August 2016 at 15:43, Niall Young &lt;niall@iinet.net.au&gt; wrote:<br/>&gt; Not sure how your example applies here Karen, there is no foo() declared in<br/>&gt; MyClass only a foo method modifier, and MyRole&#39;s foo() doesn&#39;t appear to be<br/>&gt; executed from your output?<br/><br/><br/>In the example she gave, the point was not to call MyRole&#39;s foo, only<br/>to replace it. ( Because Roles prohibit replacement by default, its a<br/>conflict that must be manually resolved )<br/><br/>Hence, &quot;around foo&quot; wraps MyRole::foo and *creates* MyClass::foo<br/>without the conflict.<br/><br/>If one wants to call MyRole::foo in the new MyClass::foo, this is done:<br/><br/> package MyClass;<br/> use Moose;<br/> with &#39;MyRole&#39;;<br/> around foo =&gt; sub {<br/> my ( $orig, $self, @args );<br/> return join q[, ], &#39;I came from the class&#39;, $self-&gt;$orig( @args );<br/> };<br/><br/><br/>This would print<br/><br/> &quot;I came from the class, I came from the role&quot;<br/><br/>Noting that:<br/><br/>&quot;$orig&quot; is the &quot;wrapped&quot; sub, MyRole::foo<br/><br/>That calling it is optional, and you can call it anywhere in the wrapper.<br/><br/>That you can intercept its return value, and modify its arguments<br/>before calling.<br/><br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2968.html Thu, 11 Aug 2016 04:15:49 +0000 Re: Why to use Moose roles ever? by Kent Fredric On 11 August 2016 at 09:25, Karen Etheridge &lt;perl@froods.org&gt; wrote:<br/>&gt;&gt; Moose roles have some limitations, such as inability to override a<br/>&gt; method in a class which &quot;with&quot;es the role.<br/>&gt;<br/>&gt; This is false. For example:<br/>&gt;<br/>&gt; {<br/>&gt; package MyRole;<br/>&gt; use Moose::Role;<br/>&gt; sub foo {<br/>&gt; &#39;I came from the role&#39;;<br/>&gt; }<br/>&gt; }<br/>&gt;<br/>&gt; {<br/>&gt; package MyClass;<br/>&gt; use Moose;<br/>&gt; with &#39;MyRole&#39;;<br/>&gt; around foo =&gt; sub {<br/>&gt; &#39;I came from the class&#39;;<br/>&gt; };<br/>&gt; }<br/><br/><br/>In fact, the above inherent conflict requiring explicit handling is<br/>seen as a &quot;feature&quot; of Moose Roles: It prohibits accidentally<br/>overriding classes in an &quot;external&quot; context, and makes it glaringly<br/>apparent that a given sub is an overrride.<br/><br/>With standard inheritance, you have to use tools to introspect the<br/>@ISA graph at runtime[1] and *then* you know which methods are<br/>overridden and where they parent to.<br/><br/>The simplest description I have of Roles in advantage to Inheritance<br/>is their design makes it easier to reason about what it is your code<br/>does, it makes it clearer from a developers perspective what the<br/>composition is, and simplifies the logic required for deep<br/>composition.<br/><br/>Because unlike Multiple inheritance where the composition is performed<br/>dynamically by the perl interpreter at runtime, with arbitrary depth<br/>@ISA&#39;s, Role composition is done in layers, where each layer is<br/>composed and made immutable prior to being composed into the next.<br/><br/>This is very different from MI, where the default intuition you&#39;ll<br/>apply to reason about &quot;what method is the next one&quot; is pretty much<br/>wrong, because counter-intuitively, if you mentally build a method<br/>resolution order for a given sub in a given class .... then compose<br/>that given class into another, instead of the method resolution of its<br/>resulting class being trivially represented in terms of its parts, it<br/>is in reality unique to its parent, because MRO&#39;s are hard.<br/><br/>For example:<br/><br/>CHILD2::foo<br/><br/>CHILD1 isa CHILD2<br/><br/>CHILD1-&gt;foo therefore calls CHILD2::foo<br/><br/>You&#39;d probably be prone to assuming that because of that:<br/><br/><br/>PARENT isa CHILD1 , CHILD3<br/><br/>PARENT-&gt;foo therefore would call CHILD2-&gt;foo<br/><br/>But it might not.<br/><br/>It might call CHILD3::foo, or CHILD4::foo , depending on what CHILD3 does.<br/><br/>^^^ this stuff does my head in and I&#39;ve spent quite a few hours<br/>bashing my head over understanding exactly how it works, and even my<br/>example case is probably wrong in some regard.<br/><br/>But the truism is that in large hierarchies,<br/>mro::get_linear_isa(PARENT) and mro::get_linear_isa(CHILD1) can very<br/>much be very different from each other.<br/><br/>And then how they&#39;re different depends on which mro is assigned to each class.<br/><br/>For producing a MRO for PARENT, /only/ the MRO assigned to PARENT is<br/>considered, even when composing its parents.<br/><br/>When producing a MRO for CHILD, /only/ the MRO assigned to the CHILD<br/>is considered, even when composing its parents.<br/><br/><br/>And this stuff will make your head hurt and your code confusing unless<br/>you have reams of tools at your disposal to answer such questions, and<br/>you know to use the tools.<br/><br/>Roles are, by comparison, much more intuitive.<br/><br/>But they come at a technical price: Lots of anonymous subs all over<br/>the place gluing everything together.<br/><br/>Which makes understanding traversal *from code* harder, and makes<br/>introspection tools somewhat &quot;blind&quot; to the dark magic that is going<br/>on.<br/><br/><br/>I&#39;d probably be inclined to argue that neither MI or Roles are very<br/>fun to use, and they&#39;re more often abused than used, so if you feel<br/>yourself reaching for them, ask yourself &quot;do I really need to?&quot;.<br/><br/>And I&#39;d be inclined to argue maybe you should consider using<br/>attributes with delegation instead of roles and inheritance.<br/><br/>That choice has its own limitations of course, notably the additional<br/>indirection comes at a performance price.<br/><br/>But it also does away with the sorts of crazy people tend to end up<br/>asking for: Instance Roles.<br/><br/>Because its much nicer to just replace an attribute with an object of<br/>a different class than it is to apply a role to an instance to achieve<br/>the same effect :)<br/><br/><br/><br/>hth<br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2967.html Thu, 11 Aug 2016 04:10:14 +0000 Re: Why to use Moose roles ever? by Niall Young On Wed, 10 Aug 2016, Victor Porton wrote:<br/><br/>&gt; Moose roles have some limitations, such as inability to override a<br/>&gt; method in a class which &quot;with&quot;es the role.<br/>&gt;<br/>&gt; But I can use an abstract base class instead of a role.<br/>&gt;<br/>&gt; Are there any real situations where roles are better than base classes?<br/>&gt; With examples, please.<br/><br/>I was going to suggest augment&#39;ing a method in a Role, which I&#39;d been planning to explore as a way of declaring interfaces and standard parameter/type checks in Classes, while consuming Roles for the implementation, but alas:<br/><br/> &quot;Roles cannot support &#39;augment&#39; at ...&quot;<br/><br/>&gt; This is false. For example:<br/><br/>Not sure how your example applies here Karen, there is no foo() declared in MyClass only a foo method modifier, and MyRole&#39;s foo() doesn&#39;t appear to be executed from your output?<br/><br/>&gt; &nbsp;&nbsp;&nbsp; package MyClass;<br/>&gt; &nbsp;&nbsp;&nbsp; use Moose;<br/>&gt; &nbsp;&nbsp;&nbsp; with &#39;MyRole&#39;;<br/>&gt; &nbsp;&nbsp;&nbsp; around foo =&gt; sub {<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &#39;I came from the class&#39;;<br/>&gt; &nbsp;&nbsp;&nbsp; };<br/><br/>&gt; say $obj-&gt;foo;&#x200B; <br/>&gt; &#x200B;# prints: I came from the class<br/><br/>--<br/>Niall Young<br/>niall@iinet.net.au http://www.nntp.perl.org/group/perl.moose/2016/08/msg2966.html Thu, 11 Aug 2016 03:43:58 +0000 Re: Why to use Moose roles ever? by Karen Etheridge &gt; Moose roles have some limitations, such as inability to override a <br/>method in a class which &quot;with&quot;es the role. <br/> <br/>This is false. For example: <br/> <br/>{ <br/> package MyRole; <br/> use Moose::Role; <br/> sub foo { <br/> &#39;I came from the role&#39;; <br/> } <br/>} <br/> <br/>{ <br/> package MyClass; <br/> use Moose; <br/> with &#39;MyRole&#39;; <br/> around foo =&gt; sub { <br/> &#39;I came from the class&#39;; <br/> }; <br/>} <br/> <br/>use 5.010; <br/>my $obj = MyClass-&gt;new; <br/>say $obj-&gt;foo; <br/>&#x200B; &#x200B; <br/># prints: I came from the class <br/> <br/> <br/> <br/> <br/>On Wed, Aug 10, 2016 at 6:00 AM, Victor Porton &lt;porton@narod.ru&gt; wrote: <br/> <br/>&gt; Moose roles have some limitations, such as inability to override a <br/>&gt; method in a class which &quot;with&quot;es the role. <br/>&gt; <br/>&gt; But I can use an abstract base class instead of a role. <br/>&gt; <br/>&gt; Are there any real situations where roles are better than base classes? <br/>&gt; With examples, please. <br/>&gt; http://www.nntp.perl.org/group/perl.moose/2016/08/msg2965.html Wed, 10 Aug 2016 21:26:08 +0000 Re: Why to use Moose roles ever? by Jed Lund Victor,<br/><br/>My experience has always been that Moose is as flexible as possible without<br/>causing fundamental logical conflicts (And their companion hard to debug<br/>issues). It is important to note that a Moose Role is not a one for one<br/>match to other programming languages implementations for a role.<br/><br/><br/>https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual/Roles.pod#Roles-Versus-Abstract-Base-Classes<br/><br/>The question you are asking also falls in the line of a bigger question<br/>that is partially outside of the scope of Moose implementation.<br/><br/><br/>http://www.javaworld.com/article/2076814/core-java/inheritance-versus-composition--which-one-should-you-choose-.html<br/><br/> https://en.wikipedia.org/wiki/Composition_over_inheritance<br/><br/>Are you aware of the following two pieces of Moose documentation? The may<br/>help to resolve some specifics around any specific implementations.<br/><br/><br/>https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual/Roles.pod#METHOD-CONFLICTS<br/><br/><br/>https://metacpan.org/pod/distribution/Moose/lib/Moose/Manual/Roles.pod#METHOD-EXCLUSION-AND-ALIASING<br/><br/>Best Regards,<br/><br/>Jed<br/><br/>On Wed, Aug 10, 2016 at 6:00 AM, Victor Porton &lt;porton@narod.ru&gt; wrote:<br/><br/>&gt; Moose roles have some limitations, such as inability to override a<br/>&gt; method in a class which &quot;with&quot;es the role.<br/>&gt;<br/>&gt; But I can use an abstract base class instead of a role.<br/>&gt;<br/>&gt; Are there any real situations where roles are better than base classes?<br/>&gt; With examples, please.<br/>&gt; http://www.nntp.perl.org/group/perl.moose/2016/08/msg2964.html Wed, 10 Aug 2016 14:44:21 +0000 Why to use Moose roles ever? by Victor Porton Moose roles have some limitations, such as inability to override a<br/>method in a class which &quot;with&quot;es the role.<br/><br/>But I can use an abstract base class instead of a role.<br/><br/>Are there any real situations where roles are better than base classes?<br/>With examples, please.<br/> http://www.nntp.perl.org/group/perl.moose/2016/08/msg2963.html Wed, 10 Aug 2016 13:00:51 +0000 Re: custom accessor_metaclass override of _inline_store (Moose 1 to2) by Toby Blake &gt; On 23 Mar 2016, at 10:46, Buddy Burden &lt;barefootcoder@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; Toby, <br/>&gt; <br/>&gt;&gt; All these attributes to which I want to apply this trigger share the same <br/>&gt;&gt; trait, so there&#39;s a logical association between the two. Is there a way I <br/>&gt;&gt; can utilise this, so I don&#39;t have to define &#39;trigger =&gt; ....&#39; for every <br/>&gt;&gt; attribute which uses this trait, i.e. have a trigger built into an <br/>&gt;&gt; attribute trait, if that makes sense? <br/>&gt; <br/>&gt; Well, I once put together an attribute trait that creates default subs (the discussion of which took place on this very list[1]), so I don&#39;t see any reason you couldn&#39;t do the same with triggers. Of course, then the trick is, is adding a trait to every attribute any better than adding a trigger to every attribute? Perhaps you could get around that by doing something to the metaclass, or perhaps your attributes _already_ all have a trait that you can piggyback on (I wasn&#39;t quite clear on that part). <br/>&gt; <br/>&gt; Anyway, I hope that discussion has something useful in it, particularly what I ended up with for my final solution.[2] I&#39;ve used that pattern a few times over the past few years. <br/> <br/>Thanks Buddy, I&#39;ll take a look a proper read-through of the thread and see <br/>what I can do. It certainly sounds useful. <br/> <br/>As to your question, yes the attributes in question already consume the <br/>trait(s) I want to expand. <br/> <br/>Cheers <br/>Toby <br/> <br/> <br/>-- <br/>The University of Edinburgh is a charitable body, registered in <br/>Scotland, with registration number SC005336. <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2962.html Wed, 23 Mar 2016 11:26:19 +0000 Re: custom accessor_metaclass override of _inline_store (Moose 1 to2) by Buddy Burden Toby,<br/><br/>&gt; All these attributes to which I want to apply this trigger share the same<br/>&gt; trait, so there&#39;s a logical association between the two. Is there a way I<br/>&gt; can utilise this, so I don&#39;t have to define &#39;trigger =&gt; ....&#39; for every<br/>&gt; attribute which uses this trait, i.e. have a trigger built into an<br/>&gt; attribute trait, if that makes sense?<br/><br/>Well, I once put together an attribute trait that creates default subs <br/>(the discussion of which took place on this very list[1]), so I don&#39;t <br/>see any reason you couldn&#39;t do the same with triggers. Of course, then <br/>the trick is, is adding a trait to every attribute any better than <br/>adding a trigger to every attribute? Perhaps you could get around that <br/>by doing something to the metaclass, or perhaps your attributes <br/>_already_ all have a trait that you can piggyback on (I wasn&#39;t quite <br/>clear on that part).<br/><br/>Anyway, I hope that discussion has something useful in it, particularly <br/>what I ended up with for my final solution.[2] I&#39;ve used that pattern a <br/>few times over the past few years.<br/><br/><br/> -- Buddy<br/><br/><br/>[1] https://www.mail-archive.com/moose@perl.org/msg02318.html<br/>[2] https://www.mail-archive.com/moose@perl.org/msg02341.html<br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2961.html Wed, 23 Mar 2016 10:46:46 +0000 Re: custom accessor_metaclass override of _inline_store (Moose 1 to2) by Toby Blake &gt; On 15 Mar 2016, at 16:13, Dave Rolsky &lt;autarch@urth.org&gt; wrote: <br/>&gt; <br/>&gt; On Tue, 15 Mar 2016, Toby Blake wrote: <br/> <br/>[...] <br/> <br/>&gt;&gt; override _inline_store =&gt; sub { <br/>&gt;&gt; my ($self, $instance, $value) = @_; <br/>&gt;&gt; my $attr = $self-&gt;associated_attribute; <br/>&gt;&gt; if ($attr-&gt;has_logger) { <br/>&gt;&gt; return sprintf(&#39;$attr-&gt;logger-&gt;($attr, %s, %s);&#39;, $instance, $value) . super; <br/>&gt;&gt; } <br/>&gt;&gt; return super; <br/>&gt;&gt; }; <br/>&gt;&gt; <br/>&gt;&gt; So, essentially, it puts a call to the attribute trait&#39;s $attr-&gt;logger <br/>&gt;&gt; subroutine in the chain when setting a value (this is needed because we <br/>&gt;&gt; have code here which needs to know when an object&#39;s attribute values have <br/>&gt;&gt; changed - this is the function of the &quot;logger&quot;). And of course this code <br/>&gt;&gt; doesn&#39;t work with Moose 2, as there is no longer an _inline_store method in <br/>&gt;&gt; Moose::Meta::Method::Accessor. <br/> <br/>[...] <br/> <br/>&gt; I think you can override Moose::Meta::Attribute-&gt;_inline_instance_set. This will work for any attribute that doesn&#39;t have an initializer (but no one uses that Moose feature). <br/> <br/>I wasn&#39;t able to get this working using <br/>Moose::Meta::Attribute-&gt;_inline_instance_set, and the more time I spent <br/>grubbing about in Moose and Class::MOP&#39;s internals the more I became convinced <br/>that it was the wrong way to do it. <br/> <br/>I _think_ I can achieve what I want by using trigger methods (it seems that <br/>when the project was originally written, triggers didn&#39;t have access to the <br/>old value, which I&#39;m presuming is why the original author went with the <br/>approach he did). However, this leads to the following question... <br/> <br/>All these attributes to which I want to apply this trigger share the same <br/>trait, so there&#39;s a logical association between the two. Is there a way I <br/>can utilise this, so I don&#39;t have to define &#39;trigger =&gt; ....&#39; for every <br/>attribute which uses this trait, i.e. have a trigger built into an <br/>attribute trait, if that makes sense? <br/> <br/>Cheers <br/>Toby <br/> <br/> <br/>-- <br/>The University of Edinburgh is a charitable body, registered in <br/>Scotland, with registration number SC005336. <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2960.html Tue, 22 Mar 2016 12:42:10 +0000 Re: custom accessor_metaclass override of _inline_store (Moose 1 to2) by Toby Blake [...] <br/>On 15 Mar 2016, at 16:13, Dave Rolsky &lt;autarch@urth.org&gt; wrote: <br/>&gt; <br/>&gt; I think you can override Moose::Meta::Attribute-&gt;_inline_instance_set. This will work for any attribute that doesn&#39;t have an initializer (but no one uses that Moose feature). <br/> <br/>Thanks for the quick reply, Dave. I&#39;ll give it a try... <br/> <br/>Cheers <br/>Toby <br/> <br/> <br/>-- <br/>The University of Edinburgh is a charitable body, registered in <br/>Scotland, with registration number SC005336. <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2959.html Tue, 15 Mar 2016 16:22:50 +0000 Re: custom accessor_metaclass override of _inline_store (Moose 1 to2) by Dave Rolsky On Tue, 15 Mar 2016, Toby Blake wrote:<br/><br/>&gt; I&#39;m trying to convert an existing project to Moose 2 (from Moose 1.15).<br/>&gt; I&#39;ve run into a tricky issue where the original author of the project (not<br/>&gt; me!) has overridden part of Moose&#39;s private API - this part has now<br/>&gt; changed. I&#39;ll try and explain the situation briefly, in the hope that<br/>&gt; somebody can advise:<br/>&gt;<br/>&gt; We have an attribute trait which uses a custom accessor_metaclass.<br/>&gt;<br/>&gt; This accessor metaclass extends &#39;Moose::Meta::Method::Accessor&#39; and<br/>&gt; overrides _inline_store, like this:<br/>&gt;<br/>&gt; override _inline_store =&gt; sub {<br/>&gt; my ($self, $instance, $value) = @_;<br/>&gt; my $attr = $self-&gt;associated_attribute;<br/>&gt; if ($attr-&gt;has_logger) {<br/>&gt; return sprintf(&#39;$attr-&gt;logger-&gt;($attr, %s, %s);&#39;, $instance, $value) . super;<br/>&gt; }<br/>&gt; return super;<br/>&gt; };<br/>&gt;<br/>&gt; So, essentially, it puts a call to the attribute trait&#39;s $attr-&gt;logger<br/>&gt; subroutine in the chain when setting a value (this is needed because we<br/>&gt; have code here which needs to know when an object&#39;s attribute values have<br/>&gt; changed - this is the function of the &quot;logger&quot;). And of course this code<br/>&gt; doesn&#39;t work with Moose 2, as there is no longer an _inline_store method in<br/>&gt; Moose::Meta::Method::Accessor.<br/>&gt;<br/>&gt; The lesson here is that we shouldn&#39;t be using parts of the private api, as<br/>&gt; they may change. However, I would like to get this working without<br/>&gt; rewriting large chunks of it. I naively tried changing _inline_store to<br/>&gt; _inline_store_value for Moose 2, but this doesn&#39;t appear to be called in<br/>&gt; the same way.<br/><br/>I think you can override Moose::Meta::Attribute-&gt;_inline_instance_set. <br/>This will work for any attribute that doesn&#39;t have an initializer (but no <br/>one uses that Moose feature).<br/><br/><br/>Cheers,<br/><br/>-dave<br/><br/>/*============================================================<br/>http://VegGuide.org http://blog.urth.org<br/>Your guide to all that&#39;s veg House Absolute(ly Pointless)<br/>============================================================*/<br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2958.html Tue, 15 Mar 2016 16:14:05 +0000 custom accessor_metaclass override of _inline_store (Moose 1 to 2) by Toby Blake Hello, <br/> <br/>I&#39;m trying to convert an existing project to Moose 2 (from Moose 1.15). <br/>I&#39;ve run into a tricky issue where the original author of the project (not <br/>me!) has overridden part of Moose&#39;s private API - this part has now <br/>changed. I&#39;ll try and explain the situation briefly, in the hope that <br/>somebody can advise: <br/> <br/>We have an attribute trait which uses a custom accessor_metaclass. <br/> <br/>This accessor metaclass extends &#39;Moose::Meta::Method::Accessor&#39; and <br/>overrides _inline_store, like this: <br/> <br/>override _inline_store =&gt; sub { <br/> my ($self, $instance, $value) = @_; <br/> my $attr = $self-&gt;associated_attribute; <br/> if ($attr-&gt;has_logger) { <br/> return sprintf(&#39;$attr-&gt;logger-&gt;($attr, %s, %s);&#39;, $instance, $value) . super; <br/> } <br/> return super; <br/>}; <br/> <br/>So, essentially, it puts a call to the attribute trait&#39;s $attr-&gt;logger <br/>subroutine in the chain when setting a value (this is needed because we <br/>have code here which needs to know when an object&#39;s attribute values have <br/>changed - this is the function of the &quot;logger&quot;). And of course this code <br/>doesn&#39;t work with Moose 2, as there is no longer an _inline_store method in <br/>Moose::Meta::Method::Accessor. <br/> <br/>The lesson here is that we shouldn&#39;t be using parts of the private api, as <br/>they may change. However, I would like to get this working without <br/>rewriting large chunks of it. I naively tried changing _inline_store to <br/>_inline_store_value for Moose 2, but this doesn&#39;t appear to be called in <br/>the same way. <br/> <br/>I&#39;d be grateful for any advice on how I can get this code working again, <br/>without substantial changes. <br/> <br/>Thanks <br/>Toby Blake <br/>School of Informatics <br/>University of Edinburgh <br/> <br/> <br/>-- <br/>The University of Edinburgh is a charitable body, registered in <br/>Scotland, with registration number SC005336. <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2016/03/msg2957.html Tue, 15 Mar 2016 16:07:27 +0000 Re: Annoying warning in Moose::Meta::Attribute; our $VERSION ='2.1604' by shtil Unfortunately a quick attempt to isolate the error failed :-). <br/><br/>The class structure I use is quite complex, used ORM to third party code and is not easy to set up outside of my environment. <br/><br/>I will see what I can do time permitting. <br/><br/>----- Original Message -----<br/><br/>From: &quot;Karen Etheridge&quot; &lt;perl@froods.org&gt; <br/>To: shtil@comcast.net <br/>Cc: &quot;Moose&quot; &lt;moose@perl.org&gt; <br/>Sent: Tuesday, January 19, 2016 12:34:11 PM <br/>Subject: Re: Annoying warning in Moose::Meta::Attribute; our $VERSION = &#39;2.1604&#39; <br/><br/>Can you possibly provide a bit of code that, when run, reproduces this warning? The &#39;package&#39; key should normally exist with a defined value. <br/><br/>many thanks! <br/><br/>On Mon, Jan 18, 2016 at 10:25 AM, &lt; shtil@comcast.net &gt; wrote: <br/><br/><br/><br/>Hi, <br/><br/>I see the following when calling $self-&gt;meta-&gt;add_attribute in my code under perl 5.10.1: <br/><br/>Use of uninitialized value in string eq at .../perl-5.10.1/lib/site_perl/5.10.1/x86_64-linux/Moose/Meta/Attribute.pm line 1035. <br/><br/>I think the following code segment: <br/><br/><br/><br/>if ( <br/>$method <br/>&amp;&amp; !$method-&gt;is_stub <br/>&amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;) <br/>&amp;&amp; ( !$self-&gt;definition_context <br/>|| $method-&gt;package_name eq $self-&gt;definition_context-&gt;{package} ) <br/>) { <br/><br/><br/><br/><br/>should look like: <br/><br/><br/><br/><br/>if ( <br/>$method <br/>&amp;&amp; !$method-&gt;is_stub <br/>&amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;) <br/>&amp;&amp; ( !$self-&gt;definition_context <br/>|| exists(self-&gt;definition_context-&gt;{package}) &amp;&amp; $method-&gt;package_name eq $self-&gt;definition_context-&gt;{package} ) <br/>) { <br/><br/>-- <br/>Yuri <br/><br/><br/><br/><br/><br/><br/> http://www.nntp.perl.org/group/perl.moose/2016/01/msg2956.html Tue, 19 Jan 2016 22:08:47 +0000 Re: Annoying warning in Moose::Meta::Attribute; our $VERSION ='2.1604' by Karen Etheridge Can you possibly provide a bit of code that, when run, reproduces this<br/>warning? The &#39;package&#39; key should normally exist with a defined value.<br/><br/>many thanks!<br/><br/>On Mon, Jan 18, 2016 at 10:25 AM, &lt;shtil@comcast.net&gt; wrote:<br/><br/>&gt; Hi,<br/>&gt;<br/>&gt; I see the following when calling $self-&gt;meta-&gt;add_attribute in my code<br/>&gt; under perl 5.10.1:<br/>&gt;<br/>&gt; Use of uninitialized value in string eq at<br/>&gt; .../perl-5.10.1/lib/site_perl/5.10.1/x86_64-linux/Moose/Meta/Attribute.pm<br/>&gt; line 1035.<br/>&gt;<br/>&gt; I think the following code segment:<br/>&gt;<br/>&gt; if (<br/>&gt; $method<br/>&gt; &amp;&amp; !$method-&gt;is_stub<br/>&gt; &amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;)<br/>&gt; &amp;&amp; ( !$self-&gt;definition_context<br/>&gt; || $method-&gt;package_name eq $self-&gt;definition_context-&gt;{package} )<br/>&gt; ) {<br/>&gt;<br/>&gt;<br/>&gt; should look like:<br/>&gt;<br/>&gt;<br/>&gt; if (<br/>&gt; $method<br/>&gt; &amp;&amp; !$method-&gt;is_stub<br/>&gt; &amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;)<br/>&gt; &amp;&amp; ( !$self-&gt;definition_context<br/>&gt; || exists(self-&gt;definition_context-&gt;{package}) &amp;&amp; $method-&gt;package_name<br/>&gt; eq $self-&gt;definition_context-&gt;{package} )<br/>&gt; ) {<br/>&gt;<br/>&gt; --<br/>&gt; Yuri<br/>&gt;<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.moose/2016/01/msg2955.html Tue, 19 Jan 2016 20:34:23 +0000 Annoying warning in Moose::Meta::Attribute; our $VERSION = '2.1604' by shtil Hi, <br/><br/>I see the following when calling $self-&gt;meta-&gt;add_attribute in my code under perl 5.10.1: <br/><br/>Use of uninitialized value in string eq at .../perl-5.10.1/lib/site_perl/5.10.1/x86_64-linux/Moose/Meta/Attribute.pm line 1035. <br/><br/>I think the following code segment: <br/><br/><br/><br/>if ( <br/>$method <br/>&amp;&amp; !$method-&gt;is_stub <br/>&amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;) <br/>&amp;&amp; ( !$self-&gt;definition_context <br/>|| $method-&gt;package_name eq $self-&gt;definition_context-&gt;{package} ) <br/>) { <br/><br/><br/><br/><br/>should look like: <br/><br/><br/><br/><br/>if ( <br/>$method <br/>&amp;&amp; !$method-&gt;is_stub <br/>&amp;&amp; !$method-&gt;isa(&#39;Class::MOP::Method::Accessor&#39;) <br/>&amp;&amp; ( !$self-&gt;definition_context <br/>|| exists(self-&gt;definition_context-&gt;{package}) &amp;&amp; $method-&gt;package_name eq $self-&gt;definition_context-&gt;{package} ) <br/>) { <br/><br/>-- <br/>Yuri <br/><br/> http://www.nntp.perl.org/group/perl.moose/2016/01/msg2954.html Mon, 18 Jan 2016 18:26:00 +0000 Convert Moose::Util::does_role to use UNIVERSAL::DOES by Kyle Bolton I was wondering if there is a reason this is not how it is implemented. I<br/>created a pull request for the change:<br/>https://github.com/moose/Moose/pull/114 http://www.nntp.perl.org/group/perl.moose/2016/01/msg2953.html Fri, 15 Jan 2016 17:37:27 +0000 Re: Distributing Roles by Karen Etheridge The MooseX::* namespace should not be used for roles -- it is for things<br/>that extend Moose itself (meta-traits etc).<br/><br/>On Tue, Dec 1, 2015 at 1:30 PM, Kent Fredric &lt;kentfredric@gmail.com&gt; wrote:<br/><br/>&gt; On 2 December 2015 at 10:00, Demian Riccardi &lt;demianriccardi@gmail.com&gt;<br/>&gt; wrote:<br/>&gt; &gt; that are shared between modules? how are they distributed.<br/>&gt;<br/>&gt; Recommendation is to use a package naming scheme like simply<br/>&gt; `Role::Serializable` or similar, taking a nod to Role::HasMessage and<br/>&gt; similar.<br/>&gt;<br/>&gt; If you can see it being possibly ported to Moose-free code one day,<br/>&gt; say, maybe using Role::Tiny or Moo::Role, I&#39;d certainly recommend the<br/>&gt; Role:: namespace.<br/>&gt;<br/>&gt; ( Or use some other top-level prefix if suitable ).<br/>&gt;<br/>&gt; If the role however is only considered useful in a Moose context, then<br/>&gt; naming it MooseX:: might be more appropriate.<br/>&gt;<br/>&gt; You want to maximise how usable a thing is, and the naming should be<br/>&gt; appropriate to how usable it is.<br/>&gt;<br/>&gt; But you don&#39;t want a name to over-advertise its usefulness and under<br/>&gt; deliver.<br/>&gt;<br/>&gt; I hope that answers your questions.<br/>&gt;<br/>&gt;<br/>&gt; --<br/>&gt; Kent<br/>&gt;<br/>&gt; KENTNL - https://metacpan.org/author/KENTNL<br/>&gt; http://www.nntp.perl.org/group/perl.moose/2015/12/msg2952.html Wed, 02 Dec 2015 03:20:13 +0000 Re: Distributing Roles by Kent Fredric On 2 December 2015 at 10:00, Demian Riccardi &lt;demianriccardi@gmail.com&gt; wrote:<br/>&gt; that are shared between modules? how are they distributed.<br/><br/>Recommendation is to use a package naming scheme like simply<br/>`Role::Serializable` or similar, taking a nod to Role::HasMessage and<br/>similar.<br/><br/>If you can see it being possibly ported to Moose-free code one day,<br/>say, maybe using Role::Tiny or Moo::Role, I&#39;d certainly recommend the<br/>Role:: namespace.<br/><br/>( Or use some other top-level prefix if suitable ).<br/><br/>If the role however is only considered useful in a Moose context, then<br/>naming it MooseX:: might be more appropriate.<br/><br/>You want to maximise how usable a thing is, and the naming should be<br/>appropriate to how usable it is.<br/><br/>But you don&#39;t want a name to over-advertise its usefulness and under deliver.<br/><br/>I hope that answers your questions.<br/><br/><br/>-- <br/>Kent<br/><br/>KENTNL - https://metacpan.org/author/KENTNL<br/> http://www.nntp.perl.org/group/perl.moose/2015/12/msg2951.html Tue, 01 Dec 2015 21:31:04 +0000 Distributing Roles by Demian Riccardi Hello Moose People, <br/> <br/>I wrote a role to serialize my HackaMol objects: <br/> <br/>https://github.com/demianriccardi/HackaMol-Roles-SerialRole <br/> <br/>I know that MooseX::Storage should solve this problem, but I couldn&rsquo;t get it to work. After writing it, I realized that it doesn&rsquo;t depend on HackaMol so it could be useful for other modules. Of course, that assumes that it is useful and/or properly implemented. Are there roles, such as this, that are shared between modules? how are they distributed. <br/> <br/>I still haven&rsquo;t completed the docs. Suggestions are very welcome. <br/> <br/>Demian <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2015/12/msg2950.html Tue, 01 Dec 2015 21:00:47 +0000 Re: $meta->superclasses() by Bill Moseley On Sat, Nov 21, 2015 at 8:01 PM, Chris Prather &lt;perigrin@prather.org&gt; wrote:<br/><br/>&gt; You are setting the superclasses explicitly so you&#39;re not inheriting from<br/>&gt; Moose::Object which defines the hooks that call BUILDARGS.<br/>&gt;<br/><br/>Maybe I&#39;m not following. The Catalyst code does this:<br/><br/><br/>&gt;<br/>&gt;&gt; my $meta = Class::MOP::get_metaclass_by_name($class);<br/>&gt;&gt; $meta-&gt;superclasses($plugin, $meta-&gt;superclasses);<br/>&gt;&gt;<br/>&gt;<br/>In this case $plugin = &#39;Catalyst::Plugin::MyPlugin&#39;, and<br/>$meta-&gt;superclasses = &#39;Catalyst&#39;. Again, Catalyst extends<br/>Catalyst::Component, where BUILDARGS is defined.<br/><br/>I&#39;m not clear how MI is suppose to work, but what I&#39;m seeing is BUILDARGS<br/>is now called in $plugin, and not in Catalyst::Component.<br/><br/>By reversing the order like this:<br/><br/>$meta-&gt;superclasses($meta-&gt;superclasses, $plugin);<br/><br/><br/>the BUILDARGS is called in Catalyst::Component and not in the $plugin.<br/><br/>This is only an issue when the plugin uses Moose, but that&#39;s pretty<br/>common. Plugins written as roles are fine, of course.<br/><br/><br/>Oh, BTW -- the init_arg problem seems to be related<br/>to MooseX::Emulate::Class::Accessor::Fast.<br/><br/>This code:<br/><br/>package Foo;<br/>use Moose;<br/>use Data::Dumper;<br/>with &#39;MooseX::Emulate::Class::Accessor::Fast&#39;;<br/><br/>has foo =&gt; (<br/> is =&gt; &#39;ro&#39;,<br/> isa =&gt; &#39;Int&#39;, # for error<br/> init_arg =&gt; undef,<br/>);<br/><br/><br/>package main;<br/>use strict;<br/>use warnings;<br/><br/>my $foo = Foo-&gt;new( { foo =&gt; &#39;bar&#39; } );<br/><br/>use Data::Dumper;<br/>print Dumper $foo-&gt;foo;<br/><br/><br/>Generates this:<br/><br/>$VAR1 = &#39;bar&#39;;<br/><br/><br/> Which should not have been set -- and clearly isn&#39;t an Int.<br/><br/>-- <br/>Bill Moseley<br/>moseley@hank.org http://www.nntp.perl.org/group/perl.moose/2015/11/msg2949.html Sun, 22 Nov 2015 18:43:21 +0000 Re: $meta->superclasses() by Chris Prather You are setting the superclasses explicitly so you&#39;re not inheriting from Moose::Object which defines the hooks that call BUILDARGS. <br/> <br/> <br/> <br/> <br/>-Chris <br/> <br/>On Sat, Nov 21, 2015 at 2:07 PM, Bill Moseley &lt;moseley@hank.org&gt; wrote: <br/> <br/>&gt; I need a bit of help understanding this code in Catalyst used for adding in <br/>&gt; Plugins: <br/>&gt; my $meta = Class::MOP::get_metaclass_by_name($class); <br/>&gt; $meta-&gt;superclasses($plugin, $meta-&gt;superclasses); <br/>&gt; This is preventing BUILDARGS from running, and I&#39;m not sure why. Can <br/>&gt; someone provide an explanation? <br/>&gt; Thanks! <br/>&gt; A Catalyst app extends &#39;Catalyst&#39;, and Catalyst extends Catalyst::Component. <br/>&gt; &lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst.pm;h=7e563cb399229facdf7271c7506b294cb0b35fb3;hb=HEAD#l5&gt; <br/>&gt; A Catalyst Component has a config *class* attribute and it also has a <br/>&gt; BUILDARGS <br/>&gt; &lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Component.pm;h=55f25c0092ec598d69484baabe728a53db37af47;hb=HEAD#l89&gt; <br/>&gt; method. BUILDARGS merges in the component&#39;s *class* configuration into the <br/>&gt; instance arguments. <br/>&gt; In other words, the component&#39;s class configuration can populate the <br/>&gt; attributes each time the instance is created. <br/>&gt; The issue I&#39;m seeing is for (non Moose::Role) plugins the code above is <br/>&gt; called and then BUILDARGS is no longer called and thus the config no longer <br/>&gt; sets attributes. <br/>&gt; The behavior of the app changes depending if loading non-Moose::Role <br/>&gt; plugins or not. <br/>&gt; So, I have three questions: <br/>&gt; First, is is incorrect for Catalyst to use &quot;sub BUILDARGS <br/>&gt; &lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Component.pm;h=55f25c0092ec598d69484baabe728a53db37af47;hb=HEAD#l89&gt;&quot; <br/>&gt; instead of using the &quot;around&quot; method modifier? <br/>&gt; Second, why is Catalyst::Component::BUILDARGS no longer called once <br/>&gt; $meta-&gt;superclasses($plugin, $meta-&gt;superclasses); <br/>&gt; is run? Is there some other BUILDARGS now overriding? <br/>&gt; And third, I have included an example below of a Catalyst app that <br/>&gt; demonstrates the behavior above. That app includes a &quot;foo&quot; attribute which <br/>&gt; is initialized by the configuration. <br/>&gt; Note that the &quot;foo&quot; attribute has &quot;init_args =&gt; undef&quot;. <br/>&gt; The &quot;foo&quot; attribute is initialized when the &quot;MyPlugin&quot; is commented out. <br/>&gt; Why is &quot;init_args =&gt; undef&quot; not preventing &quot;foo&quot; from being initialized? <br/>&gt; Here&#39;s a simple script that shows the behavior. <br/>&gt; Moose-2.1604 <br/>&gt; Catalyst-5.90103 <br/>&gt; $ cat test.pl <br/>&gt; package Catalyst::Plugin::MyPlugin; <br/>&gt; use Moose; <br/>&gt; package Foo; # A Catalyst app. <br/>&gt; use Moose; <br/>&gt; extends &#39;Catalyst&#39;; <br/>&gt; use Catalyst ( <br/>&gt; &#39;MyPlugin&#39;, # &lt;---- comment out to see change <br/>&gt; ); <br/>&gt; has foo =&gt; ( <br/>&gt; is =&gt; &#39;ro&#39;, <br/>&gt; init_arg =&gt; undef, # How is it that this attribute is ever set? <br/>&gt; ); <br/>&gt; Foo-&gt;config( <br/>&gt; foo =&gt; { some =&gt; &#39;hash&#39; }, <br/>&gt; ); <br/>&gt; Foo-&gt;setup; <br/>&gt; before dispatch =&gt; sub { <br/>&gt; my $self = shift; <br/>&gt; use Data::Dumper; <br/>&gt; *# Show what the value of the attribute is now.* <br/>&gt; *printf &quot;attribute foo is [%s]\n&quot;, Dumper $self-&gt;foo;* <br/>&gt; die &quot;dead\n&quot;; <br/>&gt; }; <br/>&gt; package main; <br/>&gt; use strict; <br/>&gt; use warnings; <br/>&gt; use Catalyst::Test &#39;Foo&#39;; <br/>&gt; request &#39;/hello&#39;; <br/>&gt; Running with the MyPlugin I get: <br/>&gt; attribute foo is [$VAR1 = undef; <br/>&gt; ] <br/>&gt; Running w/o the plugin: <br/>&gt; attribute foo is [$VAR1 = { <br/>&gt; &#39;some&#39; =&gt; &#39;hash&#39; <br/>&gt; }; <br/>&gt; ] <br/>&gt; What&#39;s also interesting is if I add this to the the Foo class then the <br/>&gt; &quot;foo&quot; attribute is set even when the MyPlugin is included. <br/>&gt; before BUILDARGS =&gt; sub {}; <br/>&gt; -- <br/>&gt; Bill Moseley <br/>&gt; moseley@hank.org http://www.nntp.perl.org/group/perl.moose/2015/11/msg2948.html Sun, 22 Nov 2015 04:01:17 +0000 $meta->superclasses() by Bill Moseley I need a bit of help understanding this code in Catalyst used for adding in<br/>Plugins:<br/><br/> my $meta = Class::MOP::get_metaclass_by_name($class);<br/> $meta-&gt;superclasses($plugin, $meta-&gt;superclasses);<br/><br/>This is preventing BUILDARGS from running, and I&#39;m not sure why. Can<br/>someone provide an explanation?<br/><br/>Thanks!<br/><br/><br/>A Catalyst app extends &#39;Catalyst&#39;, and Catalyst extends Catalyst::Component.<br/>&lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst.pm;h=7e563cb399229facdf7271c7506b294cb0b35fb3;hb=HEAD#l5&gt;<br/><br/>A Catalyst Component has a config *class* attribute and it also has a<br/>BUILDARGS<br/>&lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Component.pm;h=55f25c0092ec598d69484baabe728a53db37af47;hb=HEAD#l89&gt;<br/>method. BUILDARGS merges in the component&#39;s *class* configuration into the<br/>instance arguments.<br/><br/>In other words, the component&#39;s class configuration can populate the<br/>attributes each time the instance is created.<br/><br/>The issue I&#39;m seeing is for (non Moose::Role) plugins the code above is<br/>called and then BUILDARGS is no longer called and thus the config no longer<br/>sets attributes.<br/><br/>The behavior of the app changes depending if loading non-Moose::Role<br/>plugins or not.<br/><br/>So, I have three questions:<br/><br/>First, is is incorrect for Catalyst to use &quot;sub BUILDARGS<br/>&lt;http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst/Component.pm;h=55f25c0092ec598d69484baabe728a53db37af47;hb=HEAD#l89&gt;&quot;<br/>instead of using the &quot;around&quot; method modifier?<br/><br/><br/>Second, why is Catalyst::Component::BUILDARGS no longer called once<br/><br/> $meta-&gt;superclasses($plugin, $meta-&gt;superclasses);<br/><br/>is run? Is there some other BUILDARGS now overriding?<br/><br/><br/>And third, I have included an example below of a Catalyst app that<br/>demonstrates the behavior above. That app includes a &quot;foo&quot; attribute which<br/>is initialized by the configuration.<br/><br/>Note that the &quot;foo&quot; attribute has &quot;init_args =&gt; undef&quot;.<br/><br/>The &quot;foo&quot; attribute is initialized when the &quot;MyPlugin&quot; is commented out.<br/><br/>Why is &quot;init_args =&gt; undef&quot; not preventing &quot;foo&quot; from being initialized?<br/><br/><br/>Here&#39;s a simple script that shows the behavior.<br/><br/>Moose-2.1604<br/>Catalyst-5.90103<br/><br/>$ cat test.pl<br/>package Catalyst::Plugin::MyPlugin;<br/>use Moose;<br/><br/>package Foo; # A Catalyst app.<br/>use Moose;<br/>extends &#39;Catalyst&#39;;<br/>use Catalyst (<br/> &#39;MyPlugin&#39;, # &lt;---- comment out to see change<br/>);<br/><br/>has foo =&gt; (<br/> is =&gt; &#39;ro&#39;,<br/> init_arg =&gt; undef, # How is it that this attribute is ever set?<br/>);<br/><br/>Foo-&gt;config(<br/> foo =&gt; { some =&gt; &#39;hash&#39; },<br/>);<br/><br/>Foo-&gt;setup;<br/><br/>before dispatch =&gt; sub {<br/> my $self = shift;<br/><br/> use Data::Dumper;<br/><br/> *# Show what the value of the attribute is now.*<br/> *printf &quot;attribute foo is [%s]\n&quot;, Dumper $self-&gt;foo;*<br/><br/> die &quot;dead\n&quot;;<br/>};<br/><br/><br/>package main;<br/>use strict;<br/>use warnings;<br/>use Catalyst::Test &#39;Foo&#39;;<br/><br/><br/>request &#39;/hello&#39;;<br/><br/>Running with the MyPlugin I get:<br/><br/>attribute foo is [$VAR1 = undef;<br/>]<br/><br/><br/>Running w/o the plugin:<br/><br/>attribute foo is [$VAR1 = {<br/> &#39;some&#39; =&gt; &#39;hash&#39;<br/> };<br/>]<br/><br/><br/><br/>What&#39;s also interesting is if I add this to the the Foo class then the<br/>&quot;foo&quot; attribute is set even when the MyPlugin is included.<br/><br/>before BUILDARGS =&gt; sub {};<br/><br/><br/><br/>-- <br/>Bill Moseley<br/>moseley@hank.org http://www.nntp.perl.org/group/perl.moose/2015/11/msg2947.html Sat, 21 Nov 2015 20:07:40 +0000 Re: Replacement for MooseX::Declare? by Matija Papec <br/>Tnx for the reply, I also figured that later. :)<br/><br/><br/><br/><br/>29.09.2015, 12:06, &quot;Buddy Burden&quot; &lt;barefootcoder@gmail.com&gt;:<br/>&gt; Matija,<br/>&gt;<br/>&gt;&gt; &nbsp;it says that &quot;Support for using Function::Parameters to handle method signatures is likely to be dropped&quot;<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;https://metacpan.org/pod/Moops#Planned-Changes<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;Does this means that I have to use<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;method change_job {<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;my ( $employer,$title ) = @_;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;instead of<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;method change_job ( Object $employer, Str $title ) { }<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;?<br/>&gt;<br/>&gt; No. It means that you won&#39;t be able to use the :fp attribute for a<br/>&gt; class any more (to use Function::Parameters rather than Kavorka). But<br/>&gt; you don&#39;t want to use that anyway. :-)<br/>&gt;<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-- Buddy<br/> http://www.nntp.perl.org/group/perl.moose/2015/10/msg2946.html Thu, 01 Oct 2015 07:09:31 +0000 Re: Replacement for MooseX::Declare? by Buddy Burden Matija,<br/><br/>&gt; it says that &quot;Support for using Function::Parameters to handle method signatures is likely to be dropped&quot;<br/>&gt;<br/>&gt; https://metacpan.org/pod/Moops#Planned-Changes<br/>&gt;<br/>&gt; Does this means that I have to use<br/>&gt;<br/>&gt; method change_job {<br/>&gt; my ( $employer,$title ) = @_;<br/>&gt; }<br/>&gt;<br/>&gt; instead of<br/>&gt;<br/>&gt; method change_job ( Object $employer, Str $title ) { }<br/>&gt;<br/>&gt; ?<br/><br/>No. It means that you won&#39;t be able to use the :fp attribute for a <br/>class any more (to use Function::Parameters rather than Kavorka). But <br/>you don&#39;t want to use that anyway. :-)<br/><br/><br/> -- Buddy<br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2945.html Tue, 29 Sep 2015 10:06:09 +0000 Re: Replacement for MooseX::Declare? by rhesa Moops uses Kavorka by default, which is pretty awesome by itself. I&#39;d <br/>not worry about F::P.<br/><br/>rhesa<br/><br/>On 09/21/2015 09:45 PM, Jean-Damien Durand wrote:<br/>&gt; If Toby or other Moops&#39;s knowledgable people can answer to this question, great - I cannot -;<br/>&gt;<br/>&gt; Le lundi 21 septembre 2015, 21:27:03 Matija Papec a &eacute;crit :<br/>&gt;&gt; Hello,<br/>&gt;&gt;<br/>&gt;&gt; it says that &quot;Support for using Function::Parameters to handle method signatures is likely to be dropped&quot;<br/>&gt;&gt;<br/>&gt;&gt; https://metacpan.org/pod/Moops#Planned-Changes<br/>&gt;&gt;<br/>&gt;&gt; Does this means that I have to use<br/>&gt;&gt;<br/>&gt;&gt; method change_job {<br/>&gt;&gt; my ( $employer,$title ) = @_;<br/>&gt;&gt; }<br/>&gt;&gt;<br/>&gt;&gt; instead of<br/>&gt;&gt;<br/>&gt;&gt; method change_job ( Object $employer, Str $title ) { }<br/>&gt;&gt;<br/>&gt;&gt; ?<br/>&gt;&gt;<br/>&gt;&gt; 21.09.2015, 21:15, &quot;Jean-Damien Durand&quot; &lt;jeandamiendurand@free.fr&gt;:<br/>&gt;&gt;&gt; Hello,<br/>&gt;&gt;&gt; I enjoyed using Moops.<br/>&gt;&gt;&gt; HTH, Jean-Damien.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Le lundi 21 septembre 2015, 21:12:07 Matija Papec a &eacute;crit :<br/>&gt;&gt;&gt;&gt; https://metacpan.org/pod/MooseX::Declare is nice as an idea to remove boilerplate, but unfortunately it is deprecated.<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Can you recommend better MooseX module with similar functionality?<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Tnx in advance.<br/>&gt;<br/><br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2944.html Tue, 22 Sep 2015 12:34:22 +0000 Re: Re: Replacement for MooseX::Declare? by Jean-Damien Durand If Toby or other Moops&#39;s knowledgable people can answer to this question, great - I cannot -; <br/> <br/>Le lundi 21 septembre 2015, 21:27:03 Matija Papec a &Atilde;&copy;crit : <br/>&gt; Hello, <br/>&gt; <br/>&gt; it says that &quot;Support for using Function::Parameters to handle method signatures is likely to be dropped&quot; <br/>&gt; <br/>&gt; https://metacpan.org/pod/Moops#Planned-Changes <br/>&gt; <br/>&gt; Does this means that I have to use <br/>&gt; <br/>&gt; method change_job { <br/>&gt; my ( $employer,$title ) = @_; <br/>&gt; } <br/>&gt; <br/>&gt; instead of <br/>&gt; <br/>&gt; method change_job ( Object $employer, Str $title ) { } <br/>&gt; <br/>&gt; ? <br/>&gt; <br/>&gt; 21.09.2015, 21:15, &quot;Jean-Damien Durand&quot; &lt;jeandamiendurand@free.fr&gt;: <br/>&gt; &gt; Hello, <br/>&gt; &gt; I enjoyed using Moops. <br/>&gt; &gt; HTH, Jean-Damien. <br/>&gt; &gt; <br/>&gt; &gt; Le lundi 21 septembre 2015, 21:12:07 Matija Papec a &Atilde;&copy;crit : <br/>&gt; &gt;&gt; https://metacpan.org/pod/MooseX::Declare is nice as an idea to remove boilerplate, but unfortunately it is deprecated. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Can you recommend better MooseX module with similar functionality? <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Tnx in advance. <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2943.html Mon, 21 Sep 2015 19:45:31 +0000 Re: Replacement for MooseX::Declare? by Matija Papec Hello,<br/><br/>it says that &quot;Support for using Function::Parameters to handle method signatures is likely to be dropped&quot;<br/><br/>https://metacpan.org/pod/Moops#Planned-Changes<br/><br/>Does this means that I have to use<br/><br/> method change_job {<br/> my ( $employer,$title ) = @_;<br/> }<br/><br/>instead of<br/><br/> method change_job ( Object $employer, Str $title ) { }<br/><br/>?<br/><br/>21.09.2015, 21:15, &quot;Jean-Damien Durand&quot; &lt;jeandamiendurand@free.fr&gt;:<br/>&gt; &nbsp;Hello,<br/>&gt; &nbsp;I enjoyed using Moops.<br/>&gt; &nbsp;HTH, Jean-Damien.<br/>&gt;<br/>&gt; &nbsp;Le lundi 21 septembre 2015, 21:12:07 Matija Papec a &eacute;crit :<br/>&gt;&gt; &nbsp;&nbsp;https://metacpan.org/pod/MooseX::Declare is nice as an idea to remove boilerplate, but unfortunately it is deprecated.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;Can you recommend better MooseX module with similar functionality?<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;Tnx in advance.<br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2942.html Mon, 21 Sep 2015 19:27:12 +0000 Re: Replacement for MooseX::Declare? by Jean-Damien Durand Hello, <br/>I enjoyed using Moops. <br/>HTH, Jean-Damien. <br/> <br/>Le lundi 21 septembre 2015, 21:12:07 Matija Papec a &eacute;crit : <br/>&gt; <br/>&gt; https://metacpan.org/pod/MooseX::Declare is nice as an idea to remove boilerplate, but unfortunately it is deprecated. <br/>&gt; <br/>&gt; Can you recommend better MooseX module with similar functionality? <br/>&gt; <br/>&gt; <br/>&gt; Tnx in advance. <br/>&gt; <br/> <br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2941.html Mon, 21 Sep 2015 19:15:47 +0000 Replacement for MooseX::Declare? by Matija Papec <br/><br/>https://metacpan.org/pod/MooseX::Declare is nice as an idea to remove boilerplate, but unfortunately it is deprecated.<br/><br/>Can you recommend better MooseX module with similar functionality?<br/><br/><br/>Tnx in advance.<br/><br/> http://www.nntp.perl.org/group/perl.moose/2015/09/msg2940.html Mon, 21 Sep 2015 19:12:28 +0000 Re: MooX::HandlesVia problem by Graham Knop On 8/19/15 11:03 AM, Stephen Quinney wrote:<br/>&gt; I have a problem with using MooX::HandlesVia for attributes in roles<br/>&gt; when I consume more than one role in a class. I get:<br/>&gt; <br/>&gt; &quot;Due to a method name conflict between roles &#39;SJQ::Role::Bar and<br/>&gt; SJQ::Role::Foo&#39;, the method &#39;has&#39; must be implemented by &#39;SJQ::Baz&#39; at<br/>&gt; /usr/share/perl5/vendor_perl/Role/Tiny.pm line 215.&quot;<br/>&gt; <br/>&gt; I can&#39;t see what I&#39;m doing wrong here, any suggestions?<br/>&gt; <br/>&gt; Here&#39;s an example:<br/>&gt; <br/>&gt; {<br/>&gt; package SJQ::Role::Foo;<br/>&gt; use Moo::Role;<br/>&gt; use MooX::HandlesVia;<br/>&gt; }<br/>&gt; <br/>&gt; {<br/>&gt; package SJQ::Role::Bar;<br/>&gt; use Moo::Role;<br/>&gt; use MooX::HandlesVia;<br/>&gt; }<br/>&gt; <br/>&gt; {<br/>&gt; package SJQ::Baz;<br/>&gt; use Moo;<br/>&gt; <br/>&gt; with &#39;SJQ::Role::Foo&#39;,&#39;SJQ::Role::Bar&#39;;<br/>&gt; <br/>&gt; use namespace::clean;<br/>&gt; }<br/>&gt; <br/>&gt; my $test = SJQ::Baz-&gt;new();<br/>&gt; <br/>&gt; <br/>&gt; <br/><br/>This is a known issue: https://github.com/mattp-/MooX-HandlesVia/issues/4<br/><br/>Using namespace::clean is what I would recommend for a workaround. A<br/>proper fix will involve an additional routine in Moo that<br/>MooX::HandlesVia can use. This has been on my todo list for a while but<br/>hasn&#39;t yet made it to the top.<br/> http://www.nntp.perl.org/group/perl.moose/2015/08/msg2939.html Fri, 21 Aug 2015 15:01:20 +0000 Re: MooX::HandlesVia problem by Aaron Crane Stephen Quinney &lt;stephen@jadevine.org.uk&gt; wrote:<br/>&gt;Stephen Quinney &lt;stephen@jadevine.org.uk&gt; wrote:<br/>&gt;&gt; {<br/>&gt;&gt; package SJQ::Role::Foo;<br/>&gt;&gt; use Moo::Role;<br/>&gt;&gt; use MooX::HandlesVia;<br/>&gt;&gt; }<br/>&gt;&gt;<br/>&gt;&gt; {<br/>&gt;&gt; package SJQ::Role::Bar;<br/>&gt;&gt; use Moo::Role;<br/>&gt;&gt; use MooX::HandlesVia;<br/>&gt;&gt; }<br/>&gt;&gt;<br/>&gt;&gt; {<br/>&gt;&gt; package SJQ::Baz;<br/>&gt;&gt; use Moo;<br/>&gt;&gt;<br/>&gt;&gt; with &#39;SJQ::Role::Foo&#39;,&#39;SJQ::Role::Bar&#39;;<br/>&gt;&gt;<br/>&gt;&gt; use namespace::clean;<br/>&gt;&gt; }<br/><br/>Hi, Stephen. What&#39;s happening here is that MooX::HandlesVia looks for<br/>the &quot;has&quot; routine in the package importing it (normally the one<br/>provided by Moo or Moo::Role), wraps it with a version that<br/>understands &quot;handles_via&quot;, and replaces &quot;has&quot; in the importing package<br/>with the wrapped version. Then Moo::Role treats the wrapped &quot;has&quot; as a<br/>method implemented by the role, rather than as a declarator to be<br/>ignored; so the wrapped &quot;has&quot; implementations in each role are treated<br/>as conflicting methods, with the conflict to be resolved by the class<br/>that composes them.<br/><br/>I think this behaviour is as documented:<br/><br/>https://metacpan.org/pod/Moo::Role#CLEANING-UP-IMPORTS<br/>&quot;Moo::Role cleans up its own imported methods and any imports declared<br/>before the use Moo::Role statement automatically. Anything imported<br/>after use Moo::Role will be composed into consuming packages.&quot;<br/><br/>That is: since the wrapped &quot;has&quot; in each role isn&#39;t one of Moo::Role&#39;s<br/>own imported methods, and it&#39;s (necessarily) added after Moo::Role is<br/>imported, and it isn&#39;t cleaned up in any other way, Moo::Role is<br/>behaving as documented.<br/><br/>I suspect the simplest workaround is to add &quot;use namespace::clean&quot; to<br/>each role; this will remove the wrapped &quot;has&quot; routines.<br/><br/>&gt; To partially answer my own question, it appears that if I use &quot;with&quot; once<br/>&gt; for each role it works fine, for example:<br/>&gt;<br/>&gt; {<br/>&gt; package SJQ::Baz;<br/>&gt; use Moo;<br/>&gt;<br/>&gt; with &#39;SJQ::Role::Foo&#39;;<br/>&gt; with &#39;SJQ::Role::Bar&#39;;<br/>&gt;<br/>&gt; use namespace::clean;<br/>&gt; }<br/><br/>That means something slightly different, which is why it doesn&#39;t yield<br/>the exception you&#39;ve seen. Using one &quot;with&quot; for several roles composes<br/>the roles simultaneously-ish, specifically so that method conflicts<br/>are detected. Using multiple &quot;with&quot; calls composes them serially, and<br/>therefore does conflict detection serially, too. So the &quot;has&quot; in your<br/>::Foo gets installed as a method in ::Baz first; then the &quot;has&quot; in<br/>::Bar is ignored, because Foo&#39;s &quot;has&quot; is treated as a method that the<br/>class has implemented (which is one way to resolve a genuine role<br/>method conflict).<br/><br/>A good rule of thumb is to use serial role composition only when you<br/>know exactly why you&#39;re doing that (which is normally going to be to<br/>resolve a method conflict in favour of the implementation provided by<br/>one of the roles). In this case, my guess is that you&#39;re going to be<br/>better off fixing the spurious conflict, rather than papering over it.<br/><br/>-- <br/>Aaron Crane ** http://aaroncrane.co.uk/<br/> http://www.nntp.perl.org/group/perl.moose/2015/08/msg2938.html Thu, 20 Aug 2015 18:02:39 +0000 Re: MooX::HandlesVia problem by Stephen Quinney To partially answer my own question, it appears that if I use &quot;with&quot; once<br/>for each role it works fine, for example:<br/><br/>{<br/> package SJQ::Baz;<br/> use Moo;<br/><br/> with &#39;SJQ::Role::Foo&#39;;<br/> with &#39;SJQ::Role::Bar&#39;;<br/><br/> use namespace::clean;<br/>}<br/><br/>I&#39;m still not clear on why that is necessary though.<br/><br/><br/><br/><br/>On 19 August 2015 at 16:03, Stephen Quinney &lt;stephen@jadevine.org.uk&gt; wrote:<br/><br/>&gt; I have a problem with using MooX::HandlesVia for attributes in roles when<br/>&gt; I consume more than one role in a class. I get:<br/>&gt;<br/>&gt; &quot;Due to a method name conflict between roles &#39;SJQ::Role::Bar and<br/>&gt; SJQ::Role::Foo&#39;, the method &#39;has&#39; must be implemented by &#39;SJQ::Baz&#39; at<br/>&gt; /usr/share/perl5/vendor_perl/Role/Tiny.pm line 215.&quot;<br/>&gt;<br/>&gt; I can&#39;t see what I&#39;m doing wrong here, any suggestions?<br/>&gt;<br/>&gt; Here&#39;s an example:<br/>&gt;<br/>&gt; {<br/>&gt; package SJQ::Role::Foo;<br/>&gt; use Moo::Role;<br/>&gt; use MooX::HandlesVia;<br/>&gt; }<br/>&gt;<br/>&gt; {<br/>&gt; package SJQ::Role::Bar;<br/>&gt; use Moo::Role;<br/>&gt; use MooX::HandlesVia;<br/>&gt; }<br/>&gt;<br/>&gt; {<br/>&gt; package SJQ::Baz;<br/>&gt; use Moo;<br/>&gt;<br/>&gt; with &#39;SJQ::Role::Foo&#39;,&#39;SJQ::Role::Bar&#39;;<br/>&gt;<br/>&gt; use namespace::clean;<br/>&gt; }<br/>&gt;<br/>&gt; my $test = SJQ::Baz-&gt;new();<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; http://www.nntp.perl.org/group/perl.moose/2015/08/msg2937.html Wed, 19 Aug 2015 16:57:44 +0000 MooX::HandlesVia problem by Stephen Quinney I have a problem with using MooX::HandlesVia for attributes in roles when I<br/>consume more than one role in a class. I get:<br/><br/>&quot;Due to a method name conflict between roles &#39;SJQ::Role::Bar and<br/>SJQ::Role::Foo&#39;, the method &#39;has&#39; must be implemented by &#39;SJQ::Baz&#39; at<br/>/usr/share/perl5/vendor_perl/Role/Tiny.pm line 215.&quot;<br/><br/>I can&#39;t see what I&#39;m doing wrong here, any suggestions?<br/><br/>Here&#39;s an example:<br/><br/>{<br/> package SJQ::Role::Foo;<br/> use Moo::Role;<br/> use MooX::HandlesVia;<br/>}<br/><br/>{<br/> package SJQ::Role::Bar;<br/> use Moo::Role;<br/> use MooX::HandlesVia;<br/>}<br/><br/>{<br/> package SJQ::Baz;<br/> use Moo;<br/><br/> with &#39;SJQ::Role::Foo&#39;,&#39;SJQ::Role::Bar&#39;;<br/><br/> use namespace::clean;<br/>}<br/><br/>my $test = SJQ::Baz-&gt;new(); http://www.nntp.perl.org/group/perl.moose/2015/08/msg2936.html Wed, 19 Aug 2015 15:04:09 +0000