Re: Prototype Attributes - First Attempt at prototype attributes

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 <
[email protected]> 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 <
>> [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
>>>
>>>
>