Re: Several Questions

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
>>
>
>