Re: Prototype Attributes - First Attempt at prototype attributes

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 <
> [email protected]> 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 <[email protected]> wrote:
>>> On Wed, Dec 17, 2008 at 3:07 AM, Christopher Brown
>>> <[email protected]> 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
>>