Re: Using Moose::Role as an Exporter replacement

I just noticed this code again a work, and then found this email that I
don't see every received a response.

Can anyone provide their insight?


On Sun, Sep 18, 2011 at 11:34 PM, Bill Moseley <moseley@hank.org> wrote:

> I'm on vacation and have finally found wireless to check out the svn logs
> back at work.  I found a bunch of new Moose Roles created that are being
> used like one might use Exporter.  Here's an example:
>
> package App::Role::Date;
> use strict;
> use warnings;
> use Moose::Role;
> use DateTime;
> use Carp;
>
>
> sub date_is_in_future {
>     my ( $test_date ) = @_;
>
>     croak 'first arg to date_is_in_future must be DateTime'
>         unless ref( $test_date ) eq 'DateTime';
>
>     my $now = DateTime->now();
>
>     if ( $test_date >= $now ) {
>         return 1;
>     }
>
>     return 0;
> }
>
> Then in a number of classes (most not Moose-based to start with) that have
> attributes that hold a DateTime there's code added like this:
>
> with 'App::Role::Date';
>
> ...
>    my $dt = $self->start_time;
>    if ( date_is_in_future( $dt ) ) {
>       ....
>    }
>
> Perhaps I'm being pedantic, but that makes my skin crawl.   For one thing
> it's using a Role like Exporter.   And "date_is_in_future" seems like it
> should be a method on the DateTime object (although seems "$dt >
> DateTime->now" is just as easy to write.)  And, of course, the above will
> fail on DateTime subclasses.  Not to mention returning 0 or 1 gives me the
> willies.
>
> Are there other more Moose-specific reasons that this code is problematic
> that I can point out?
>
>
>
> --
> Bill Moseley
> moseley@hank.org
>



-- 
Bill Moseley
moseley@hank.org

• Using Moose::Role as an Exporter replacement by Bill Moseley
• Re: Using Moose::Role as an Exporter replacement by Bill Moseley
• Re: Using Moose::Role as an Exporter replacement by Chris Prather
• Re: Using Moose::Role as an Exporter replacement by Jed Lund