On Thu, 16 Jan 2003, Dave Rolsky wrote:
>
[moved here from below:]
> No, they don't. I was responding to _other_ suggestions! I don't think
> you've read the whole thread.
I did indeed read the entire thread. But as my mailreader doesn't
really do threading, I may have become confused while doing so and
perhaps picked the wrong message to respond to. I apologize if this is
indeed the case.
> Yes, I know. I was just responding to people's suggestions that things be
> loaded on demand.
And I was responding to your suggestion that loading on demand
necessarily hurts mod_perl users. My point was that we could let
everyone else enjoy the convenience of on-demand loading, as long as we
just document which modules need to be explicitly preloaded by mod_perl
users to achieve optimum performance.
But I guess it doesn't really matter. See below.
> Fine, no extra methods. In that case, I prefer to do parsing explicitly,
> ala:
>
> my $dt = DateTime::Parse::Extended->parse( "the 3rd Sunday after next" );
>
> As opposed to implicitly:
>
> my $dt = DateTime->new( extended => "the 3rd Sunday after next" );
>
> I think the former is clearer. Though a bit wordy. Of course, there's
> nothing prevent parsing modules from offering exportable subroutines.
Apart from the wordiness, I really have no objection to the former
syntax. More importantly, it occurs to me that if we go with the former
syntax (or any of its proposed variations), support for the latter could
be easily added later, should it be found desirable after all.
> For the actual API, how about this:
>
> # dies if DateTime::Formats::MySQL is not loaded
> my $dt = DateTime->parser('MySQL')->from_datetime( $mysql_dt_string );
>
> $dt->formatter('MySQL')->as_datetime(...); # additional params if needed
That'd be fine by me, too.
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"My previous boss . . . was never afraid to make himself look silly if it
was a step to acquiring new knowledge, and we all respected him for that."
-- Alan J. Flavell in comp.lang.perl.misc
