Well,
You could do like what we did with MooseX::Storage, which exports a
Storage function such that:
with Storage(format => 'JSON', io => 'File');
is equivalent to:
with 'MooseX::Storage::Basic', 'MooseX::Storage::Format::JSON',
'MooseX::Storage::IO::File';
So you could export an 'opts' function which would do the role
composition for you, such that ...
opts qw(user password);
would be equivalent to:
with 'My::App::User', 'My::App::Password';
as for if this would be useful for CPAN, I think if you generalized
it enough, and added support for namespacing the user/password roles,
etc. I suspect it would be helpful/useful. I am not sure about the
MooseX::Common:: namespace though, it seems too general.
- Stevan
On Jun 23, 2008, at 2:39 AM, Christopher Brown wrote:
Stevan et al,
Sorry about that, I hit send by accident just before climbing on a
plane ( returning from a week in Chicago for YAPC and other
events ). Thanks for the quick reply.
I spend a good deal of churning out command-line and gui
application based on Moose class. I find myself continually typing:
has 'user' => ...
has 'password' => ...
has 'tmp' => ...
How these get defined rarely ever changes. Nor do the tests for
them change. I am trying to create a module which implements
common attributes and sets up the framework for retrieving them
from command line arguments, stdin, a event driven GUI interface,
etc. It would be really nice to have the ability to say simply:
use Moose;
opts qw(user password );
Where user might refer to MooseX::Common::user.pm and password
might refer to MooseX::Common::password.pm. Both user.pm and
password.pm would define a Moose::Role that has a simple 'has'
function that defines the full behavour of the common attribute.
Opts is similar to the load_plugins function of Gillermo's
MooseX::Object::Pluggable but allow for Class based loading of
plugins rather than instance based. I plan on using this with
MooseX::Getopt. And this where it get troublesome. When the
MooseX::Getopt constructor, new_with_options is called, the options
are retrieved. And I then cannot use the MooseX::Object::Pluggable
instance based loading.
Some things that strike me as possible are:
1. Just keep it simple and use Moose::Roles. But then instead
of a simple opt as described above, I have to say:
with qw( MooseX::Common::user MooseX::Common::password );
Not too bad, I suppose and barring any simple solutions for
introducing opts, I will probably do this.
2. Use Moose Classes instead of roles, but I only have a vague
notion of how this would work. Having heard the horizontal reuse
talk at YAPC, this seems to go against the what seems like a
perfect model for the horizontal reuse pattern.
One final question:
If I were to unlease this on CPAN ... any thoughts on whether it
would be useful and what I should call it?
Thanks in Advance,
Chris
I also plan on extending these with MooseX::Getopt;
password might be are (to be) defined as Moose roles and gathered
using MooseX::Getopt and loaded by a mechanism such as
MooseX::Object::Pluggable.
On Sun, Jun 22, 2008 at 8:36 PM, Stevan Little
<[EMAIL PROTECTED]> wrote:
Christopher,
Well it all depends on how you want to extend them, some ways are
better then others.
To extend the whole of Moose, take a look at the section on
Extending and Embedding Moose in the Moose.pm POD. It explains how
you can wrap the Moose system and extend it for your needs.
To just extend the options that 'has' accepts, you can do that with
custom attribute metaclasses or attribute traits (there are
cookbooks on both of these).
Short of that I would need to know more what you want the syntax
too look like to give you any better clues.
- Steva
On Jun 22, 2008, at 12:03 PM, Christopher Brown wrote:
Hi All,
Quick questions: Is it advisable to extend the core Moose keywords.
( I
think the answer is no). But if so, what is the best way to do it.
Background:
I am trying to extend MooseX::Getopt to provide patterns for the
standard
GNU Command Line Options
