Front page | perl.datetime |
Postings from January 2003
Re: Picking up the ball
Thread Previous
|
Thread Next
From:
Matthew Simon Cavalletto
Date:
January 9, 2003 23:34
Subject:
Re: Picking up the ball
Message ID:
EE99248D-246D-11D7-8C3D-003065AFEA5E@cavalletto.org
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 calendars
>
> -- Must be interoperable with base datetime object! This means that
> we can convert back and forth between the two on demand.
Clearly 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.
> - 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 simonm@cavalletto.org
Evolution Softworks www.evolutionsoftworks.com
Web Application Development and Technical Consulting Services
Thread Previous
|
Thread Next