Front page | perl.datetime |
Postings from January 2003
From: Dave Rolsky
January 14, 2003 11:16
Message ID: Pine.LNX.firstname.lastname@example.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
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
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::Parse::MySQL; # this needs a better name
my $dt = DateTime::Parse::MySQL->new_datetime( $mysql_dt );
print DateTime::Parse::MySQL->mysql_datetime( $dt );
my $dt = DateTime->from_mysql_datetime( $mysql_dt );
House Absolute Consulting
by Dave Rolsky