John Peacok wrote:
> Dave Rolsky wrote:
> > 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 )
>
> I don't like the former mode any more than I like the latter. ;~) A
> profusion of nearly identical methods is, IMNSHO, even more prone to the
> typo problems you mentioned above. Especially if the methods are just
> going to be run_on_names which describe their actions, thus making sure
> the source code is littered with extra text for no good reason. I would
> argue that
>
> DateTime->new($mysql_dt, parse => mySQL);
>
> is much more readable and just as easy to program.
I tend to agree. I just started reading through this list (just heard
about it on use.perl.org) and this thread and the one concerning "which
day is #1" bother me (granted those are the only ones I've looked at
:)
I was thinking that a sort of DBI/DBD dichotomy could be applied to
DateTimes but along multiple dimensions. Something like this:
my $dt = DateTime(
parser => DateTime::Parser::MySQL,
formatter => DateTime::Formats::strftime,
week_starts_at => DateTime::Weekdays::Sunday,
);
Yes, I know it looks hideous, but this is just off the cuff.
This syntax is the verbose version; reasonable defaults could be applied
to make the common cases simpler.
use DateTime ( Defaults => {
parser => DateTime::Parser::MySQL,
formatter => DateTime::Formats::strftime,
week_starts_at => DateTime::Weekdays::Sunday,
}
);
# all DateTime thingies we create use the above defaults
# unless we specify otherwise
my $dt1 = DateTime->new;
my $dt2 = DateTime->new(parser => DateTime::Parser::RFC822);
> Just my 2 cents. I fully accept that you are the driver here and you
> will win the argument if it comes down to it.
Hey, I know! Let's fork and take the TimeDate namespace to make a
superficially similar but completely different set of date/time
routines. <ducking and running> ;-) * 5
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
