On Thu, 16 Jan 2003, Dave Rolsky wrote:
> On Thu, 16 Jan 2003, Ilmari Karonen wrote:
>
> > 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.
I think the former is much, much better. The clearer the better in
variable names and API calls. Wordiness be damned.
<feedback>
> > > 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.
Umm, improper grammar caused by hasty response caused by a teensy-weensy
overdose of hubris? Everyone is in awe of your commitment and energy, Dave
... sometimes you're becoming a bit short with folks, though ...
</feedback>
> Anyway, here's where the parsing/formatting bit stands.
[ ... ]
> - parsing and formatting will be done via explicit methods, as opposed to
> additional parameters to DateTime->new or a generic DateTime->format
> method.
Good.
> 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.
Blech. Nothin' in the middle of the road but a yellow stripe and dead
armadilloes.
> 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.
You wouldn't have to type that more than once, would you? Any code that
needs to be used more than once should be wrapped in a sub anyway. And
besides,
my $dt = DateTime->parser('MySQL')->from_datetime( $mysql_dt_string );
appears to be longer than
my $dt = DateTime::Formats::MySQL->parse( $mysql_dt_string );
as well as less clear.
> It also has the additional side effect of allowing you to create and hold
> onto formatters and parsers.
Not an issue if you write a three-line function.
- nick
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
