You are setting the superclasses explicitly so you're not inheriting from Moose::Object which defines the hooks that call BUILDARGS.
-Chris On Sat, Nov 21, 2015 at 2:07 PM, Bill Moseley <mose...@hank.org> wrote: > I need a bit of help understanding this code in Catalyst used for adding in > Plugins: > my $meta = Class::MOP::get_metaclass_by_name($class); > $meta->superclasses($plugin, $meta->superclasses); > This is preventing BUILDARGS from running, and I'm not sure why. Can > someone provide an explanation? > Thanks! > A Catalyst app extends 'Catalyst', and Catalyst extends Catalyst::Component. > <http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=blob;f=lib/Catalyst.pm;h=7e563cb399229facdf7271c7506b294cb0b35fb3;hb=HEAD#l5> > A Catalyst Component has a config *class* attribute and it also has a > BUILDARGS > <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> > method. BUILDARGS merges in the component's *class* configuration into the > instance arguments. > In other words, the component's class configuration can populate the > attributes each time the instance is created. > The issue I'm seeing is for (non Moose::Role) plugins the code above is > called and then BUILDARGS is no longer called and thus the config no longer > sets attributes. > The behavior of the app changes depending if loading non-Moose::Role > plugins or not. > So, I have three questions: > First, is is incorrect for Catalyst to use "sub BUILDARGS > <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>" > instead of using the "around" method modifier? > Second, why is Catalyst::Component::BUILDARGS no longer called once > $meta->superclasses($plugin, $meta->superclasses); > is run? Is there some other BUILDARGS now overriding? > And third, I have included an example below of a Catalyst app that > demonstrates the behavior above. That app includes a "foo" attribute which > is initialized by the configuration. > Note that the "foo" attribute has "init_args => undef". > The "foo" attribute is initialized when the "MyPlugin" is commented out. > Why is "init_args => undef" not preventing "foo" from being initialized? > Here's a simple script that shows the behavior. > Moose-2.1604 > Catalyst-5.90103 > $ cat test.pl > package Catalyst::Plugin::MyPlugin; > use Moose; > package Foo; # A Catalyst app. > use Moose; > extends 'Catalyst'; > use Catalyst ( > 'MyPlugin', # <---- comment out to see change > ); > has foo => ( > is => 'ro', > init_arg => undef, # How is it that this attribute is ever set? > ); > Foo->config( > foo => { some => 'hash' }, > ); > Foo->setup; > before dispatch => sub { > my $self = shift; > use Data::Dumper; > *# Show what the value of the attribute is now.* > *printf "attribute foo is [%s]\n", Dumper $self->foo;* > die "dead\n"; > }; > package main; > use strict; > use warnings; > use Catalyst::Test 'Foo'; > request '/hello'; > Running with the MyPlugin I get: > attribute foo is [$VAR1 = undef; > ] > Running w/o the plugin: > attribute foo is [$VAR1 = { > 'some' => 'hash' > }; > ] > What's also interesting is if I add this to the the Foo class then the > "foo" attribute is set even when the MyPlugin is included. > before BUILDARGS => sub {}; > -- > Bill Moseley > mose...@hank.org
