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