Stevan, It went through okay. I don't know about anyone else, but I noticed that it takes up to a couple hours for uploads to work their way through the system.
http://search.cpan.org/~ctbrown/MooseX-Attribute-0.01/ I actually suspected that the name, MooseX::Attribute is a bad one and commented as such in the documentation. I wil change the name other Moosers feedback. ( My utmost wish, of course, is to have the functionality moved into Moose core. I see it as an important feature. The object of the module that I wrote is perhaps mostly to show that how it can be done in the existing Moose framework with little performance impact. ) Not withstanding my wishes, my next proejct will be to create these extensible, reusable attributes for the GNU command line options list: http://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table This might properly live in the vacated MooseX::Attribute namespace? No. Thanks for the feedback, I will apreciate any more suggestions, Chris On Sat, Jan 3, 2009 at 12:22 PM, Stevan Little < stevan.lit...@iinteractive.com> wrote: > Chris, > > I am not seeing it on CPAN yet, nor in the PAUSE incoming directory, you > might want to check to make sure it went through. > > Without looking at the code, my only issue would probably be with the name. > MooseX::Attribute is a very general name and not really descriptive of what > it actually does, I think perhaps MooseX::DeferredAttribute would be a > better name. > > - Stevan > > > > > On Jan 3, 2009, at 2:37 PM, Christopher Brown wrote: > > Hi All, >> >> I would like your feedback on MooseX::Attribute, uploaded to CPAN moments >> ago. This is my first attempt at creating extensible attributes. Please >> consider the code pre-alpha. >> >> A prototype attribute is provided by the sugar word 'attribute' that can >> be >> used in place of 'has'. The 'attribute' defer adding attributes until all >> attribute specifications are done. It maintaining a list of >> attribute_prototypes, those from which specifications can be borrowed and >> attribute_installs, those which get installed into the object. Using a >> method modifier 'before 'new', these attributes are installed. >> >> I also discovered some nice side-effects. Deferred attribute construction >> allows the ability to 'apply' specifications across attributes. Say, for >> example, that you want to make attributes A, B, C 'ro' while making D,E,F >> 'rw'. This can easily be done. I do not believe that it is so easy in >> the >> present Moose world. >> >> Anyhow, please let me know what you think. >> >> Happy New Year! >> >> Chris >> >> >> >> >> On Wed, Dec 17, 2008 at 11:01 AM, Christopher Brown < >> cbr...@opendatagroup.com> wrote: >> >> Shawn et al., >>> >>> Thanks for the more constructive criticism. Keep it comin'. My >>> responses are inline: >>> >>> On Wed, Dec 17, 2008 at 1:39 AM, Sartak <sar...@gmail.com> wrote: >>> >>>> On Wed, Dec 17, 2008 at 3:07 AM, Christopher Brown >>>> <cbr...@opendatagroup.com> wrote: >>>> >>>>> package MooseX::Attribute::DateTime; >>>>> >>>>> has 'datetime' => ( >>>>> is => 'rw' , >>>>> isa => 'DateTime' , >>>>> coerce => 1 , >>>>> metaclass => 'MooseX::Getopt::Meta::Attribute', >>>>> cmd_aliases => 'time' >>>>> ); >>>>> >>>> >>>> I hope that the Getopt options here wouldn't actually be in the >>>> generic MooseX::Attribute::DateTime! >>>> >>> >>> Oh agreed! I needed an example. It wouldn't be a bad idea to have >>> everything set up for handle Getopts; but this should be off by >>> default. >>> >>> package myApp; >>>>> use Moose; >>>>> with 'MooseX::Attribute::DateTime'; >>>>> >>>>> has 'begin' => ( prototype => 'datetime', cmd_aliases => 'begin' ); >>>>> has 'end' => ( prototype => 'datetime', cmd_aliases => 'end' ); >>>>> ... >>>>> >>>> >>>> I don't think overriding "has" is the right solution. How's this? I >>>> rather like it: >>>> >>>> package myApp; >>>> use Moose; >>>> use MooseX::Attribute::DateTime; >>>> >>>> has_date begin => (cmd_aliases => 'begin'); >>>> has_date end => (cmd_aliases => 'end'); >>>> >>>> "has_date" could be configurable, you just pass the keyword you want >>>> to "use MooseX::Attribute::DateTime". Alternatively, you could go even >>>> further and allow extra parameters to be specified in the "use" line, >>>> such as: >>>> >>>> use MooseX::Attribute::DateTime ( >>>> 'has_date', >>>> needs_date => { >>>> required => 1, >>>> }, >>>> ); >>>> >>>> needs_date begin => (cmd_aliases => 'begin'); >>>> has_date end => (cmd_aliases => 'end'); >>>> >>> >>> Hmm. Not bad. It certainly gives the right construction. My fear >>> would be that this would tend to cause an explosion of has_* subs. >>> Not a bad thing per se, but not as clean as I am hoping. Might have >>> to live with it. >>> >>> Data::OptList (already used in several places in Moose as you know) >>>> would make this trivial. >>>> >>> >>> I think I will certainly make use of the excellent Data::OptList. >>> >>> Thanks, >>> >>> Chris >>> >>> >
