On Tue, 14 Jan 2003, Dave Rolsky wrote:
>
> 2. I really want to avoid runtime module loading. This is because I have
> a mod_perl bias, and with mod_perl, it's much better to load modules at
> compile time (in the parent Apache process) than at runtime, where the
> 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!
my $dt = DateTime->new( MySQL => $sqldate );
> 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' );
(But is there actually a reason why we couldn't pass all the parameters
to the parser anyway?)
> 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.)
> 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.
> 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 )
Hmm. We appear to disagree on that principle. I do think there are
circumstances where adding methods may simplify the interface, but I
don't think this is 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.
> 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).
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"... programs that work in spite of themselves are not what should be
guiding language design." -- Sean M. Burke on the perl5-porters list
