Okay, yeah that makes more sense.
Still think perhaps it is better as a Something::Factory distro which
also contains a MooseX:: in it to allow it to be used as an attribute.
In general we are trying to discourage the use of MooseX:: unless it
really truly is an extension to Moose. There are a lot of MooseX::
modules that aren't that (I am as guilty of this as anyone, if not the
most guilty).
- Stevan
On Mar 5, 2009, at 3:01 AM, Ian Sillitoe wrote:
No, My::App->new should return an instance of My::App not of
My::View::HTML.
The idea of a ->new being a factory method is confusing IMO.
Sorry - either the example wasn't clear or I'm missing something
from sketching this out without testing the implementation (I'm away
from a proper terminal atm). The intention was for it to still work
exactly as you say:
My::App->new; # returns My::App
My::App->new( view => 'HTML' )->view; # returns My::View::HTML
Allows:
$app = My::App->new( view => 'HTML' );
$app->view; # My::View::HTML
The attribute trait 'PluginFactory' provides plugin factory
functionality to the 'view' attribute using the specified
plugin_base ''My::View'
has 'view',
is => 'ro',
isa => 'My::View',
traits => [ 'PluginFactory' ],
plugin_base => 'My::View';
The intention is that this validates incoming strings like:
has 'view',
isa => enum( 'Text', 'XML', 'HTML' )
(although the list is build from the plugin modules present so you
don't need to change the code to allow new plugins to be loaded)
Also, and more usefully, you get an object back which obviously has
associated functionality.
Ian Sillitoe
CATH Team -- http://cathdb.info