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

Re: Parser Interface (Was Re: Picking up the ball)

Thread Previous | Thread Next
Dave Rolsky
January 13, 2003 11:51
Re: Parser Interface (Was Re: Picking up the ball)
Message ID:
On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote:

> What's the benefit of making this distinction between core and "other"
> formats?

Because "core" parsing would be available simply by doing:

  use DateTime;

That's about it.

> Why not define a parser interface and include the basic formats as
> modules in the main distribution?

What distro it's in is not the issue.  It's really a question of whether
or not users must load another module to do parsing, that's all.

> 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

It's over 100 lines cause it needs refactoring.  That's on my todo list.

>    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')
>    );

Actually, I have some ideas for this.  Something like:

  use DateTime;
  use DateTime::Parse::MySQL;

  my $dt = DateTime->from_mysql_datetime( $mysql_dt );

So the parsing modules would just add methods to the DateTime namespace.


House Absolute Consulting

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