[Catalyst] Plugin attributes and Moose

[John Napiorkowski]

To speak to the issue with MooseX::Emulate::Class::Accessor::Fast I don't think this is supposed to mix and match with Moose 'has' style attributes as in your example, see the docs:

https://metacpan.org/pod/MooseX::Emulate::Class::Accessor::Fast

Basically this is meant to be the fast easy way to move an old CA based class to Moose. If you are going to define attributes via 'has' then I'd just say you should stop using it.  You see this used in a bunch of older plugins to 'moosify' them.  But IMHO those should be really Moose or Moo top to bottom.  Just again no volunteers to do it and it mostly just works anyway.

Again, I would say if you are writing new code to just not use any of those compatibility shims.  best of luck -jnap


On Sunday, November 22, 2015 3:03 PM, Bill Moseley <moseley at hank.org> wrote:



I wanted to note something (before the week gets started and time vanishes) about how Catalyst is behaving, and see if it's expected.

I asked about this on the Moose list, so sorry if you already saw this.

A Catalyst app extends Catalyst::Component, which has a BUILDARGS sub to merge in class configuration when creating instances of components.

This is how configuration can set initial values on attributes in Models, Views, Controllers, and the application class itself. 

If a (non-role) Moose-based plugin is loaded (which is common) it's added to the app's inheritance like this:

$meta->superclasses($plugin, $meta->superclasses);

 Which can be thought of like this:

@App::ISA = ( qw/ Catalyst::Plugin::Foo  Catalyst / );

The result then is that BUILDARGS in Catalyst::Component is no longer called, and then attributes in the App class are no longer populated from the config.

So, the behavior changes depending on what plugins are brought in.

Another odd issue I came against is that MooseX::Emulate::Class::Accessor::Fast causes odd behavior of Moose attributes.   This role is widely used in Catalyst.

In the code below note how the "foo" attribute has init_arg => undef to prevent it from being initialized.  With the the role not only is it initialized, but with a value that isn't an "Int".



package Foo;
>use Moose;
>
>
>with 'MooseX::Emulate::Class::Accessor::Fast';
>
>has foo => (
>    is  => 'ro',
>    isa => 'Int', # for error
>    init_arg => undef,
>);
>
>
>
>package main;
>use strict;
>use warnings;
>
>
>my $foo = Foo->new( { foo => 'bar' } );
>
>
>use Data::Dumper;
>print Dumper $foo->foo;


Generates 'bar', which is not an Int.

$VAR1 = 'bar';


Comment out "with 'MooseX::Emulate::Class::Accessor::Fast';" and it behaves as expected.   Also comment out "init_arg" and Moose will complain about the string not begin an Int.

-- 

Bill Moseley
moseley at hank.org
_______________________________________________
List: Catalyst at lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/