Re: Several Questions

Stevan et al.,

Thanks.  That is exactly what I want to do.  I will take a look at
MooseX::Storage and read on how the Moose exports works.  ( It might be a
little foreign to me since I am an Exporter guy.  I know, I know.  I may
lean again on the list for another questions or so. but I will give it my
best shot. )

Okay ... MooseX::Common is a little weak.  MooseX::Getopt::Commom?
MooseX::Attributes::Common?  MooseX::CommonAttributes?  MooseX::Attributes?

I'll have to sleep on this one.  As you can see, I have more than a little
trepidation of picking a stoopid name.

Cheers,

Chris



On Mon, Jun 23, 2008 at 7:52 AM, Stevan Little <
[email protected]> wrote:

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