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@hank.org
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@hank.org