On Thu, 16 Jan 2003, John Peacock wrote:
> I've been thinking about the API for parsers and storage methods and I have a
> different suggestion than what has been discussed before. The current model
> seems to assume that there is a single DateTime object type, regardless of
> backend storage method. Or at the very least, the current model will require
> additional backend work to completely emulate the existing scheme. Although
> Date::ICal seems to be a fine base, others have already mentioned wanting to
> implement in other internal schemes, for example TAI64.
Yes, I expect there to be other DateTime.pm API implementations using
different internals, TAI64 being one obvious example. A pure XS
implementation may also be useful, just for speed.
I should also point out I'm moving the ical-specific bits to
DateTime::Formats::ICal. This'll be a good example parser/formatter, and
there's already working code for it, and tests that can be tweaked a bit.
It will also handle parsing & formatting DateTime::Duration objects, which
other DateTime::Formats::* modules may need to do as well.
> I suggest that the parsing modules (currently referred to as DateTime::Formats)
> be strictly limited to parsing some subset of the possible input formats and
> return an object with a few standard methods which would retrieve a normalized
> representation. Then, the parsed and normalized object could be used by the
> chosen backend to store the date for later processing.
>
> For example, DateTime::Formats::XXXX would return an object which would have the
> following methods:
>
> $obj->as_array # "big endian" array of date/time values
> $obj->as_unix_time # seconds since the epoch
> $obj->as_string # some sort of "standard" text format
> $obj->as_ical # the ICal normalized format
How about this instead:
my $formatter =
DateTime::Formats::ISO8601->new
( class => 'DateTime::Implementation::TAI64' );
my $dt = $formatter->parse( ... );
The assumption here is that there is a standard set of arguments which can
be given to the constructor, which follows from the assumption that all
DateTime "core object" implementations share an API. These constructor
arguments would probably be:
year, month, day
hour, minute, second
time_zone
or something extremely similar.
This assumes that DateTime implementations would implement the same API as
DateTime.pm (maybe with extra methods), but that seems like a _good_
implementation. I think it'd be confusing as hell if DateTime.pm offered
one set of get methods and DateTime::Implementation::TAI64 offered another
set.
> I've actually been programming some sample code, so for this object:
>
> my $prs = DateTime::Formats::ISO8601("1998-06-03T12:30:01");
>
> you would have these possible methods:
>
> $prs->as_array => ARRAY(0x8064c68)
> 0 1998
> 1 06
> 2 03
> 3 12
> 4 30
> 5 01
> $prs->as_unix_time => 899483401
> $prs->as_string => '1998-06-03T12:30:01'
> $prs->as_ical => '19980603T123001'
I think we should assume that creating a format/parse object will be
one step, and actual parsing/formatting will be a different one.
I don't think the parser should be directly responsible for producing
anything other than "DateTime.pm API-compliant object", which may or may
not actually _be_ a DateTime.pm object.
> I would suggest that the DateTime objects themselves simply be a wrapper for the
> DateTime::Storage::XXXX module, which itself would rely on the DateTime::Format
> modules to provide it with a normalized date format. The DateTime->new() method
> would be very shallow:
>
> ...
> my $self = {
> DATE => DateTime::Storage->new(DateTime::Format->new($val)),
> };
>
> bless $self, $class;
So what's implemented in DateTime.pm in this idea? Nothing? If nothing,
it might as well just return an object in a different class. I don't
think I understand what you're suggesting.
> I have DateTime::Formats::ISO8601 done (well formed ISO dates only); I attach it
> for your pleasure. I can work on DateTime::Formats::Date_Parse for the more
By "Date_Parse" do you mean complex Date::Manip style parsing?
As to DateTime::Thingy::TAI64, I think it needs to do the following:
- implement the same API as DateTime.pm, possibly adding some TAI64
methods if that's useful
- inherit from DateTime.pm - this follows from the former. There's no
reason to implement a method like "year_0", which is defined in
DateTime.pm as:
sub year_0 { $_[0]->year - 1 }
There's a number of other methods in DateTime.pm it'd be pointless to
override as well, along these same lines.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
