Re: Picking up the ball

Front page | perl.datetime | Postings from January 2003

Thread Previous | Thread Next

From:

Dave Rolsky

Date:

January 10, 2003 00:32

Subject:

Re: Picking up the ball

Message ID:

Pine.LNX.4.51.0301100226560.25009@urth.org

On Fri, 10 Jan 2003, Matthew Simon Cavalletto wrote:

> > - 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.

There's no need for this base class to be _abstract_.  It might as well
implement a reasonable implementation of the API.

> 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.

Another module is free to implement the same API, whether or not it's a
subclass of the "standard" implementation.

> > - 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.

Interoperability will be based on _interface_, not implementation.  In
other words, all modules need to support some methods like "->ical", or
"->julian_time" (returns days and seconds), or whatever.

So we might have:

  DateTime::Calendar::Discordian;

  sub new
  {
      my $class = shift;
      my %p = @_;

      if ( exists $p{datetime} )
      {
          return $class->new_from_object( $p{datetime} );
      }

      ...
  }

  sub new_from_object
  {
      my $class = shift;
      my ($jd, $js) = shift->julian_time;

      # convert

      return $self;
  }

No other module should ever care how the base class is implemented
internally.

> > - 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.

Yeah, I was thinking about this recently and I realized some events are
best returned as a DateTime object (Christmas, for example), while others
are really best returned as a DateTime::Timespan (Ramadan), and so on.

It's just a nice namespace for "modules that calculate event
date/time/spans/sets"


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Thread Previous | Thread Next