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