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

$meta->superclasses()

Thread Next
From:
Bill Moseley
Date:
November 21, 2015 20:07
Subject:
$meta->superclasses()
Message ID:
CAKhN_m7L3izmtyv9J31DVxjG+v186=ncQCiiGiAx3mJwZHXpWQ@mail.gmail.com
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 Next


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