On Thursday, January 9, 2003, at 05:04 PM, Dave Rolsky wrote:
This is so freaking lame! [...] it's time to change it.
Agreed; thanks for making another push in this direction.
1. Stop herding cats. [...] 2. Use the DateTime:: namespace. [...] 3. Start with set of base data objects [...]
All good proposals.
- DateTime::Base [...] A good candidate for this is the existing Date::ICal code, with a bunch of the Time::Piece convenience methods thrown in for good measure.I'd suggest having an abstract base class one level above the ICal implementation. This class could establish the minimum interface that was required to interoperate with the rest of the module suite, without locking every single implementation into the internal model used by ICal.
As a contrived example, if I'm collecting paleo-biology records and need to deal with lots of approximate and very-long-ago dates (hundreds of millions of years), it'd be nice to be able to construct a custom DateTime object that used a different internal representation, perhaps "years BCE, as an integer", but still adhere to some standard API, so that I could have Spans and Deltas of those times without having to write everything again from scratch.
- DateTime::Calendar - other calendarsClearly this requirement for interoperability is a core issue for this effort -- but along the same lines as above, rather than requiring that every object be based on our one master format internally, it should be sufficient to define an interface that allows one to query a calendar object for the types of conversion it supports, and then perform those conversions when needed.
-- Must be interoperable with base datetime object! This means that we can convert back and forth between the two on demand.
- DateTime::Event - Rich proposed DateTime::Holiday but Abigail pointed out that there are plenty of events that aren't holidays, per se.It'd be nice to see these modules implemented in a way that lets us easily instantiate them as an infinite DateTime::Set object, so that we can use the iteration and bounds-checking methods that provides.
So, who's ready to chew ass and kick some bubble-gum?!
I'm definitely interested in contributing to this effort. -Simon -- Matthew Simon Cavalletto [EMAIL PROTECTED] Evolution Softworks www.evolutionsoftworks.com Web Application Development and Technical Consulting Services
