Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
Thread Previous
|
Thread Next
From:
Dave Rolsky
Date:
January 10, 2003 01:51
Subject:
Re: Picking up the ball
Message ID:
Pine.LNX.4.51.0301100345490.25009@urth.org
On Fri, 10 Jan 2003, Matt Sergeant wrote:
> Don't throw out the baby with the bathwater. There's some good things
> going for Time::Piece right now:
>
> 1. It has a *lot* of users.
> 2. It has quite a bit of good and mostly reusable code.
> 3. It's the API blessed/designed by Larry Wall (that may or may not be a
> good thing ;-)
> 4. The API can support non-epoch times, so changing the internals should
> be invisible to the user.
>
> Just because the internals are a little screwey doesn't mean we shouldn't
> just retrofit it to a Date::ICal backend. I see no reason not to do that,
> rather than starting again from scratch.
Yeah, that's my point. I like the API, but the internals may or may not
work. I think we agree. My point was that for now I'd like to focus on
the API, with the assumption (not set in stone) that the Date::ICal code
will form the core of the DateTime object. If there is Time::Piece code
that we can reuse as well, that's great.
> The other thing being that the whole datetime area is a huge piece of
> work, and is really hard to understand the finer points of the little
> corners of it. And if you get it wrong you screw up people's software in
> really hard to debug ways. What I'm saying here is we don't really have
> the manpower/money to just scrap everything and start again.
I agree. That's why I specifically mentioned stealing as many existing
tests as possible. For example, if we reimplemented the Time::Piece API
with entirely new code we'd at least have a decent test suite to throw it
at.
I _know_ that a lot of the implementation for things I'm proposing exists
in various modules. In some cases, we'll be able to cut 'n' paste code.
In others, we'll be able to borrow algorithms
This is the reason I want to talk first about the API. That's what is
missing. We have lots of great functionality, but every piece has a
different, and incompatible, API. That's what sucks!
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
Thread Previous
|
Thread Next