Re: Picking up the ball

Front page | perl.datetime | Postings from January 2003

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