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

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

Thread Previous | Thread Next
From:
Matthew Simon Cavalletto
Date:
January 13, 2003 12:31
Subject:
Re: Parser Interface (Was Re: Picking up the ball)
Message ID:
F2BED643-2735-11D7-935D-003065AFEA5E@cavalletto.org
On Monday, January 13, 2003, at 02:51  PM, Dave Rolsky wrote:

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

We can move the parsing to format modules and load them automatically.

> It's really a question of whether or not users must load another 
> module to do parsing, that's all.

The suggestion on the table is that even the "core" parsing be placed 
in another package, but that this be transparent to end-users.

>>    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.
>
> Actually, I have some ideas for this. [...] the parsing modules would 
> just add methods to the DateTime namespace.

Ick -- what's the advantage of doing it this way?

It strikes me as a lot more logical to keep those methods in their own 
namespace and simply call them when needed.

Looking at the two alternatives, does the second really seem clearer?

   use DateTime;
   my $dt = DateTime->new( 'MySQL' => $mysql_dt );
   print $dt->to_string( 'MySQL' );

   use DateTime;
   use DateTime::Parse::MySQL;
   my $dt = DateTime->from_mysql_datetime( $mysql_dt );
   print $dt->to_mysql_string();

-Simon


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About