Hello Moose Aficionados,
WIth nary a replied to my previous post, it was recommended by Shawn Moore
to resubmit with a further explanation of my aims. What I am proposing and
trying to develop is a prototype attribute mechanism such that the
programmer can specify a attribute from a role and optionally overriding its
defaults. What I am thinking is the ability to do something akin to:
package MooseX::Attribute::DateTime;
has 'datetime' => (
is => 'rw' ,
isa => 'DateTime' ,
coerce => 1 ,
metaclass => 'MooseX::Getopt::Meta::Attribute',
cmd_aliases => 'time'
);
...
package myApp;
use Moose;
with 'MooseX::Attribute::DateTime';
has 'begin' => ( prototype => 'datetime', cmd_aliases => 'begin' );
has 'end' => ( prototype => 'datetime', cmd_aliases => 'end' );
...
The object MyApp would then have attributes begin and end with the proper
cmd_aliases.
By way of background, prototype attributes are much like Shawn's
parametrized roles. ( Perhaps, they should be called parametrized
attributes? ) The goal is to make an attribute specification reusable and
customizable. After all, why not allow parametrization at a lower level of
detail than roles? Attribute specification is already highly repetitive.
Right? Many objects tend to reuse attributes. And these attributes often
align with function ( and often existing CPAN modules!) such as with the
File and DateTime. It's perlish to make these modular and put them in Perl
modules.
There are three potential ways of implementing prototype attributes:
_1_
The naive way is using normal attributes in standard roles. This is simple
and straightforward. But implementing attributes this way, limits one to
hardcoded attribute names and definitions. For example, if a role defines
an attribute as 'rw', you could not easily specify it as 'ro' and not before
it was already installed. The limitations of this approach is clear.
_2_
You could also implement using Shawn's excellent MXRP . This is a perfectly
valid solution except for some annoyances:
1. Attributes are implemented 'with' a role syntax. This makes for
complicated code; Attributes specifications occur with two disparate
syntactic constructions one with 'has' and another with 'with'.
2. The development of the attribute is needlessly complex. Under the MXRP
definition, the definition requires coding with a lot of forethought by the
developer. The developer must to foresee the uses of his attribute. Under
the attribute prototype design, the developer of an attribute is only
required to define an attribute with sensible defaults. ( An ancillary
benefit is to entice CPAN authors to develop prototype attributes (and
types) for their objects. The number who actual do will be proportional to
how easy it is. And the prototype design makes this easy. )
_3_
Another method would be to rewrite/overload/intercept the has subroutine. I
haven't thought about the entire ramifications or complications here. But
this is likely the best way to handle this.
There are several advantages for prototype mechanism:
1. Favors reusable attributes that allows for customization ( the goal ).
2. Clean, readable code. Attributes are specified as attributes have always
been specified:
has 'attribute' => ( ... ); ( a requirement? )
2a. Easier to debug
2b. Less code
3. By default, the attribute is an attribute out-of-the-box
4. Makes it easy for CPAN authors to Moose-ify their modules. ( ancillary
benefit )
5. Other languages/platform have similar abilities ( competitive )
Why do I care? Well, I think that 95%+ of attributes are very rote. It
would be easy to put together a list of 100 attributes . And have 95% of my
attribute writing done. Of the three things that programs do 1) accept
input 2) program logic 3) output. This would nearly eliminate the accepting
of the input. My day-to-day job as a programmer gets 1/3 easier. (
Actually .95 * 1/3 easier )
I would appreciate your thoughts,
Chris
