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
>
