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

Reply via email to