On Thu, 16 Jan 2003, Jonathan Scott Duff wrote:
> Alternate reality:
>
> use DateTime ( Defaults => {
> parser => DateTime::Parser::Mysql,
> parserargs => ...
> });
> my $dt = DateTime::parse($mysql_dt_string);
>
> or
>
> DateTime::parserargs(...);
> my $dt = DateTime::parse($mysql_dt_string);
>
> or
>
> my $dt = DateTime::parse($mysql_dt_string, { parserargs => ... });
The main objection I have to these is that they assume just 1 parser at a
time. But it's not unrealistic to imagine code that integrates several
data sources needing multiple parsers.
> > > > It also has the additional side effect of allowing you to create and hold
> > > > onto formatters and parsers.
>
> my $p = DateTime::Parser::Mysql->new(...);
> my $f = DateTime::Formats::Mysql->new(...);
Yep, this is what I was suggesting. Except parsing and formatting will
probably be in the same namespace, DateTime::Formats. I suppose we could
tell module authors to create one distro with two modules though.
> > my $format = DateTime::Formats::MySQL->new( ... );
> >
> > my $dt = $format->parse_datetime( $mysql_dt );
> >
> > $format->as_timestamp( datetime => $dt, length => 8 );
>
> my $f = DateTime::Formats::Mysql->new(...);
> my $dt = DateTime->new($mysql_dt,
> { parser => DateTime::Parser::Mysql });
> print $f->as_timestamp($dt, { length => 8 });
Those two are really close, except that as I said before I really do
prefer explicit versus implicit usage of the parser.
Again, what do you do in the case of:
my $dt = DateTime->new( year => 2000, month => 12, day => 30,
parser => 'DateTime::Parser::MySQL' );
Yes, you can throw an error ("inconsistent parameter in call to new()").
But why even make it possible?
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
