On Thu, 16 Jan 2003, Ilmari Karonen wrote:
> > 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.
>
> This doesn't necessarily rule out the ->new( MySQL => $sqldate ) syntax,
> though, as long as we provide a way to preload the necessary parser
> modules. The simplest way would probably be this:
>
> use DateTime;
> #use DateTime::Parse::MySQL; # mod_perl users uncomment this!
Yes, I know. I was just responding to people's suggestions that things be
loaded on demand.
> > a. I like named parameters for any method that is likely to ever take
> > more than one parameter.
>
> Assuming that the parser itself needs to take more than one parameter,
> those could always be wrapped in a hashref or an arrayref:
>
> my $dt = DateTime->new( Discordian => { year => 3169,
> season => 'Chaos',
> day => 16 },
> Extra => 'something not for the parser' );
Sure, that'd work, although your above example confuses two things,
parsing and non-Gregorian calendars. To create a Gregorian date from a
Discordian date, you'd do:
my $disco = DateTime::Calendar::Discordian->new( year => 3169,
season => 'Chaos',
day => 16 );
my $dt = DateTime->new( object => $disco );
> (But is there actually a reason why we couldn't pass all the parameters
> to the parser anyway?)
I'd prefer not to, because its hard to distinguish between passing extra
parameters intentionally and passing extra parameters as a mistake. I'm
thinking of using Params::Validate for parameter validation and it
intentionally disallows extra parameters (at least by default).
> > 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.
>
> I don't quite get this. Are you talking about something else? Such as
> "format guessing"? (Which would be doomed to fail anyway.)
Someone was indeed suggesting format guessing, yes. Not me.
> > c. It would require DateTime.pm to know about all possible parsing
> > extensions. (Ok, a registration scheme could get around this)
>
> No it wouldn't. Just have it require() the extension on demand. As I
> said, mod_perl users can always pre-load all the extensions they'll use.
>
> There _are_ times when symrefs (well, dynamic package names, in this
> case) are appropriate. I'd say this is one of them.
>
> Heck, even if we eliminated the dynamic loading, and made the preloading
> mandatory, this would still be cleaner than what you'd suggested.
I've made at least two different suggestions. You're only responding to
one of them!
> In particular, I dislike your suggestion because those extra methods end
> up polluting the DateTime:: namespace. I don't like namespace pollution
> at all -- if I wanted method names like from_mysql_datetime(), I'd write
> my scripts in PHP.
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.
And in the latter case, how do I distinguish between additional parameters
that indicate another parsing module, and a typo? How about if someone
does this:
my $dt = DateTime->new( year => 2000, month => 12, day => 17,
ISO => '2001-12-11T09:01:23' );
What wins?
> > 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.
>
> They do explain your position admirably. It's just that it seems to me
> that you've overlooked certain issues here (such as the simple solution
> to the mod_perl issues that I've described above).
No, they don't. I was responding to _other_ suggestions! I don't think
you've read the whole thread.
Anyway, here's where the parsing/formatting bit stands.
- The namespace will almost certainly be Date::Formats::*
- Modules in this namespace will implement parsing, formatting, and/or
both.
- strftime may or may not be built-in to DateTime.pm (this is a _very_
minor point, I think)
- parsing and formatting will be done via explicit methods, as opposed to
additional parameters to DateTime->new or a generic DateTime->format
method.
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
This is kind of a compromise between a bunch of proposals.
It does avoid adding methods to the DateTime namespace, which should make
a number of people happy. It uses methods instead of parameters, which
makes _me_ happy. It allows arbitrarily complex sets of parameters to be
passed to parsers and formatters, and easily. And the code in DateTime.pm
needed to support it is extremely minimal. It doesn't require constantly
typing long class names like "DateTime::Formats::MySQL->parse(...)" does.
It also has the additional side effect of allowing you to create and hold
onto formatters and parsers.
my $mysql_formatter = $dt->formatter('MySQL');
print $mysql_formatter->as_datetime;
print $mysql_formatter->as_timespan(8);
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
