develooper Front page | perl.moose | Postings from November 2015

Re: $meta->superclasses()

Thread Previous | Thread Next
From:
Chris Prather
Date:
November 22, 2015 04:01
Subject:
Re: $meta->superclasses()
Message ID:
1448164860963.a7e4ee79@Nodemailer
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 <moseley@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
> moseley@hank.org
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About