On Tue, Sep 20, 2011 at 04:09:35PM +0300, Bill Moseley wrote:
> Our apps (and the modules they use) use DateTime extensively. We have the
> need to do a lot of common operations on DateTime objects, for example
> checking if a DateTime object is in the future. So, I'm wondering what's
> the recommended approach to provide these common methods.
>
> I think what I'd do is add a method $dt->is_in_future, but I'm not clear how
> we can subclass DateTime since "DateTime->new" is used directly in code we
> don't control.
>
> The other approach is a utility module using Exporter[*] -- then do
> is_in_future( $dt ), but I'm not thrilled by that.
Why do you need to add a new method? Perl is not Ruby :)
Why don't you want to make a library of utility functions? This looks quite
straight-forward to me:
package MyApp::Util::DateTime;
use strict;
use warnings;
use Exporter 'import';
our @EXPORT_OK = qw(date_in_future);
sub date_in_future
{
my $dt = shift;
return $dt > DateTime->now;
}
> * This started out as a Moose question because I saw some code added to our
> app that was using Moose Roles as an Exporter-replacement -- that is using
> "with" to bring in the role but then calling the code as functions not as
> methods.
Yep, and you were quite correct to be horrified by that approach and to
want to remove it immediately.
--
"Men and nations behave wisely once they have
exhausted all other alternatives." - Abba Eban
. . . . .
Karen Etheridge, [email protected] GCS C+++$ USL+++$ P+++$ w--- M++
