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 =======================*/
