develooper Front page | perl.datetime | Postings from January 2003

Parser Interface (Was Re: Picking up the ball)

Thread Previous | Thread Next
Matthew Simon Cavalletto
January 13, 2003 10:47
Parser Interface (Was Re: Picking up the ball)
Message ID:
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" 

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

The same type of architecture could also facilitate supporting 
arbitrary stringification into whichever format was desired...


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About