Parsing/Formatting API

Front page | perl.datetime | Postings from January 2003

Thread Next

From:

Dave Rolsky

Date:

January 14, 2003 11:16

Subject:

Parsing/Formatting API

Message ID:

Pine.LNX.4.51.0301141257130.25009@urth.org

I'm going to lay out my requirements for how this will work in order to
constrain the discussion, because I really have a firm idea of how this
needs to work.


My constraints are:

1. A module should be able to choose to implement parsing, formatting, or
both.  For example, if we want to add "knowledge of MySQL" to our DateTime
objects, we really want both parsing of the formats MySQL returns _and_
formatting for mysql.  OTOH, for parsing human-readable strings like "the
Tuesday after next", we probably won't bother with producing the same kind
of output.

2. I really want to avoid runtime module loading.  This is because I have
a mod_perl bias, and with mod_perl, it's much better to load modules at
compile time (in the parent Apache process) than at runtime, where the
module ends up being loaded once per child process.  See
http://perl.apache.org/docs/1.0/guide/performance.html#Preloading_Perl_Modules_at_Server_Startup
for an explanation of why this is important.

For very small amounts of code, it wouldn't be a big deal, but for things
like extended parsing, which will be bulky, it's quite important.

No arguments about whether mod_perl is important, please.  It's a huge,
important area for Perl development.  And a system which causes major
problems for mod_perl is not viable, period.

3. "DateTime->new( 'somerandomthing' )" is not going to happen.  This is
bad for several reasons:

 a. I like named parameters for any method that is likely to ever take
    more than one parameter.

 b. It's way too magical and could cause very weird effects.  A simply
    typo could cause the extended parsing to be loaded, which would be
    very surprising for end users.

 c. It would require DateTime.pm to know about all possible parsing
    extensions.  (Ok, a registration scheme could get around this)

4. Given the choice between adding more parameters or more methods, I
prefer to add more methods, which is why I dislike

  DateTime->new( mysql => $mysql_dt )

as opposed to

  DateTime->from_mysql_datetime( $mysql_dt )


Hopefully the above guidelines explain why I've been so vehemently opposed
to some proposals so far.  There really is a guiding set of principles at
work here, I'm not just flipping coins.


So given those constraints, here are the potential options on the table,
_so far_ (I welcome others that fit into the above constraints).

  use DateTime;
  use DateTime::Parse::MySQL; # this needs a better name
  my $dt = DateTime::Parse::MySQL->new_datetime( $mysql_dt );
  print DateTime::Parse::MySQL->mysql_datetime( $dt );

or

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


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Thread Next