Front page | perl.datetime |
Postings from January 2003
On Monday, January 13, 2003, at 01:07 PM, David Wheeler wrote:
> On Sunday, January 12, 2003, at 11:42 PM, Matt Sergeant wrote:
>
>> Parsing should not be in a base date time class though - it has no
>> place there. It should *return* a base date time object, but putting
>> generators in the same class doesn't make sense to me.
>
> I disagree. I think that some very fundamental parsing needs to go
> into the base class. You should be able to construct a DateTime object
> for whatever date and time you need, and to do that, it has to be able
> to parse a date/time argument. But nothing fancy, just a few formats
> should be supported in the base class, including epoch time, ICal, and
> maybe ISO 8601. Other than that, I agree that all other date parsing
> should go into another module.
What's the benefit of making this distinction between core and "other"
formats?
Why not define a parser interface and include the basic formats as
modules in the main distribution?
This type of design should encourage separation of concerns, and help
to avoid monolithic implementations -- the current DateTime::new sub is
over 100 lines long... The overhead of one more method call seems like
a small price to pay.
my $dt = DateTime->new( ICal => '20030113' );
# Causes DateTime to load the ICal format module and request that
# it parse the data and return it in a standard numeric form.
# Equivalent to the following:
require DateTime::Format::ICal;
my $dt = DateTime->new( rd_sec =>
DateTime::Format::ICal->parse_into_ratadie_and_seconds('20030113')
);
The same type of architecture could also facilitate supporting
arbitrary stringification into whichever format was desired...
-Simon
Thread Previous
|
Thread Next