On Tuesday, January 14, 2003, at 02:16 PM, Dave Rolsky wrote:
My constraints are:
1. A module should be able to choose to implement parsing, formatting, or both. [...]
Definitely.
Agreed, in a mod_perl context you'll definitely be able to pre-load the parsers you're going to need -- just require or use them from your startup script. If some vocal set of people particularly like runtime loading, it would be easy to add an option in for this later, but you're right that there's no need for this in the core API.2. I really want to avoid runtime module loading. [...]
3. "DateTime->new( 'somerandomthing' )" is not going to happen. [...]
Agreed.
The "more parameters" method is intended to simply be a gateway onto the "more methods" implementation.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 )
There really is a guiding set of principles at work here, I'm not just flipping coins.Understood -- I'm just trying to balance these very sensible principles with one of my own: "if you end up with one class that has hundreds of methods, you've probably done something wrong."
use DateTime::Parse::MySQL; # this needs a better name
I've suggested "DateTime::Format::MySQL".
There should be no need to repeat the word "mysql" in the method name, since the package name clearly disambiguates that.print DateTime::Parse::MySQL->mysql_datetime( $dt );
So, here's the option I'm proposing:
use DateTime;
use DateTime::Format::MySQL;
my $dt = DateTime::Format::MySQL->new_datetime( $mysql_dt );
print DateTime::Format::MySQL->format_string( $dt );
I'm also proposing the addition of gateway methods where appropriate; these are just dynamic dispatch methods for convenience, hopefully only a few lines of code each.
my $dt = DateTime->new_from_format( 'MySQL', $mysql_dt );
print $dt->format_string( 'MySQL' );
It seems to me that this effectively combines the best features of the two existing proposals -- each set of parser/formatter goes into a separate namespace and a polymorphic API, *AND* there's an interface directly accessible from the DT objects themselves
-Simon