Re: Parsing/Formatting API

[Matthew Simon Cavalletto]

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.

2. I really want to avoid runtime module loading. [...]

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.

3. "DateTime->new( 'somerandomthing' )" is not going to happen. [...]

Agreed.

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 )

The "more parameters" method is intended to simply be a gateway onto the "more methods" implementation.

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".

  print DateTime::Parse::MySQL->mysql_datetime( $dt );

There should be no need to repeat the word "mysql" in the method name, since the package name clearly disambiguates that.

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