Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
From: Dave Rolsky
January 10, 2003 02:13
Re: Picking up the ball
Message ID: Pine.LNX.email@example.com
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
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 DateTime.pm! 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 DateTime.pm.
> 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
> 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
my $order_d = time;
my $ship_d = $order_d + ONE_DAY * 5;
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
out "I CANNOT HANDLE TIME ZONE CONVERSIONS. I AM BUT A WEE SUBSET OF
House Absolute Consulting