develooper Front page | perl.datetime | Postings from January 2003

Re: Picking up the ball

Thread Previous | Thread Next
Dave Rolsky
January 10, 2003 02:13
Re: Picking up the ball
Message ID:
On Fri, 10 Jan 2003, John Peacock wrote:

> > 1. Stop herding cats.  If existing module authors don't want to play,
> > then screw them.
> One word for you: wrappers.  I want to call to your attention the methodology
> pursued by Tels when he rewrote the Math::BigInt/BigFloat core modules.  He
> identified (with my careful prodding) the minimal subset of operations required
> as the backend and extracted that from the main code.  Then he wrote (without my
> help at all ;~) interface layers to various extended precision math modules, hence:
> 	Math::BigInt::Calc - pure Perl, comes with M::BI
> 	Math::BigInt::FastCalc - XS implementation of above
> 	Math::BigInt::Pari - uses Math::Pari => PARI library
> 	Math::BigInt::BitVect - uses Bit::Vector
> 	Math::BigInt::GMP - XS using GMP library

This sounds like the Strategy pattern.  Ooh, I mentioned a pattern!  I
feel special.

Anyway, this is the whole point of having a common API!  If there's a
predictable API that DateTime implements, there's nothing to stop someone
from reimplementing it in C using the libtai64 library, for example.

Maybe those modules (if they exist) could go in

> > - DateTime::Object
> I have to agree with the others that the base class should be DateTime itself,
> with, as I suggested above, a set of modules to support the actual operations,
> which themselves could be replaced by other interpretations/implementations.

I'm warming to taking DateTime too.  It's just so wonderfully arrogant.
"Want to do DateTime stuff in Perl?  Use!  And there's a
bunch _legacy_, don't-play-nice-with-each-other Date:: and Time:: modules
on CPAN too ;)"

> One issue I see is that the DateTime:: namespace will likely contain both
> implementation classes, e.g. DateTime::Parse, as well as subclasses, e.g.
> DateTime::Discordian.  This will make the strict OO people crazy, but it is
> certain the Perl Way.

Actually, that'd be DateTime::Calendar::Discordian, according to Rich
Bowen's proposal.  But yeah, there'll be a lot DateTime:: things that
don't actually inherit from

> I'll display my bias here:  I am developing in a corporate environment where the
> time variable is frequently completely unimportant and the only interesting
> issue is dates.  I care about days between, or adding days, or business days or
> whatever.  I think any system that will be good for me will permit me to
> completely supress the time aspect without requiring me to think about it.
> For example:
> 	use DateTime qw(NoTime);
> 	my $order_dt = new DateTime "today"; # 2003/01/10
> 	my $ship_dt  = $order_dt + 5;        # 2003/01/15
> etc.
> I don't care whether the underlying implementation is TAI64 or Date::Calc, just
> as long as I can say "Don't care about attoseconds!" to the code and have it DWIM.

Well, you can do this with Date::ICal right now.

 my $order_d = Date::ICal->new( epoch => time );
 printf( '%04d/%02d/%02d', $order_d->year, $order_d->month, $order_d->day );
 my $ship_d  = $order_d + Date::ICal::Duration->new( days => 5 );
 printf( '%04d/%02d/%02d', $ship_d->year, $ship_d->month, $ship_d->day );

And here's a very good example of how Date::ICal could benefit from the
Time::Piece API:

 use Time::Piece;
 use Time::Seconds;

 my $order_d = time;
 print $order_d->mdy('/');
 my $ship_d = $order_d + ONE_DAY * 5;
 print $ship_d->mdy('/');

The question of at what granularity the object stores dates and times is
an _implementation_ issue.  So we might very well have
DateTime::Implementation::DateOnly.  Of course, this will only implement a
subset of the standard DateTime API, so it's docs damn well better scream


House Absolute Consulting

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About