develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About