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
