Re: Several Questions

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
>