Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
Thread Previous
|
Thread Next
From:
John Peacock
Date:
January 10, 2003 02:00
Subject:
Re: Picking up the ball
Message ID:
3E1E99A7.6070709@rowman.com
Dave Rolsky wrote:
> I don't know why, but it's time to change it.
Good for you! Count me in somewhere between moral support and actually
dedicating myself to coding. ;~) No, seriously, I cannot promise any specific
level of support, but I will be very interested in the API discussion. And that
is where we should spend all of our time, IMHO.
> 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
etc.
The interface is all important here, but it should be too difficult to come up
with the universe of operations we want to operate with. The basic ops that
overloading supports, plus a very few is probably sufficient.
>
> 2. Use the DateTime:: namespace.
If you use it, they will come...
> 3. Start with set of base data objects around which functionality can be
> built.
>
> - 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.
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.
<snip some good example classes>
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.
Good luck!
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
Thread Previous
|
Thread Next