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