> -----Original Message----- > From: Rick Measham [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 05, 2004 4:38 PM > To: Ofer Nave > Cc: [EMAIL PROTECTED] > Subject: Re: new fan has questions/comments/suggestions > > > On 6 Aug 2004, at 9:07 AM, Ofer Nave wrote: > > 1) Why have different 'new' and 'from_epoch' constructors? > Couldn't > > one > > always use 'new' and have the module figure out what information to > > initiatlize itself with by seeing if either the 'year' or > 'epoch' name > > parameter was passed? I think it would provide a cleaner and more > > consistent interface. > > I'll leave this one to Dave, but I'm guessing its because of > the amount > of code in the constructors. You'd have to wrap them into extra subs > really. And then you'd have to test the parameters passed to new(). > You'd have to make sure that if epoch() was included then no hour() > minute() second() etc were included. > > Not too hard, really, so maybe Dave has another reason.
Well, since year is the only required argument for the current new(), you could switch on either year or epoch being present and document the order in which you check - so if year is looked for first, and both year and epoch are included, it pretends it didn't see epoch. Likewise with including both epoch and hour but not year - it didn't see year, and saw epoch, so it will run in epoch mode, and not even pay attention to hour. Just like it wouldn't pay attention to billybob if I passed it ( epoch => time(), billbob => 'thornton' ). But it's not that important. I personally like standardizing on a single constructor (new), but I can see the logic behind wanting to emphasize standardizing on the independent date portion format and making you think twice before constructing on epoch, since we're all trying to move away from epoch. > > 2) However, if you continue to provide different constructors, then > > when > > using from_epoch, why require the 'epoch' named paramter? Why not > > assume a > > single argument is an epoch value? > > All parameters are named in DateTime. It's a convention we use and > while it can be annoying for single-parameter methods it saves > confusio. > > The from_epoch constructor can take up to three parameters: > $dt = DateTime->from_epoch( > epoch => time(), > time_zone => 'Australia/Melbourne', > locale => 'en_AU', > ); Ok, good point. Standards are good, and I forgot that there are additional parameters to from_epoch. > If you start assuming a single argument is a particular parameter, > which do you go with in other cases. If you change one > method, you have > to be consistent. > $dt = DateTime->new( 34 ); > Is that 00:00:34 or 00:34:00 or 0034-00-00? Well, since year is the only required argument, you'd probably assume it was year, and therefore the date would be 0034-00-00 00:00:00.0! :) But that's probably a habit to encourage/allow. > > 3) You could offer one or more of these: > > > > # prints '2003-05-04 12:55:10'; > > print $dt->ymd_hms; > > print $dt->ymdhms; > > # prints '2003-05-04 12:55:10.123456789'; > > print $dt->ymdhmsn; > > We offer strptime() in the core because of the plethora of > options that > could be offered: > $dt->ymd; > $dt->dmy; > $dt->mdy; > $dt->hm; > $dt->hms; > $dt->hmsn; > $dt->ymd_hm; > $dt->dmy_hm; > $dt->mdy_hm; > $dt->ymd_hms; > $dt->dmy_hms; > $dt->mdy_hms; > $dt->ymd_hmsn; > $dt->dmy_hmsn; > $dt->mdy_hmsn; > > And that's just the numeric posibilities. Once you want day or month > names you have to increase the list exponentially. Yes, I know, but the idea is to make it convenient to do the most common things (which is why ymd() and hms() are, in fact, available), and it seems to be like a combined ymd_hms would qualify that list. Especially being the ISO8601 standard time format, and that you often want to print both date and time. > HOWEVER, that said, I'd like to see some sort of a default format > method: > $dt->set_default_format($strftime_format); > print $dt->default_format; > print "Stringified with default: $dt"; That would be nice. I'm also considering subclassing DateTime and calling it something simliar but specific to my company, with an extra generic sub like 'print()' that will always print the date in whatever format my company chooses to standardize on (which will be ISO8601's YYYY-MM-DD HH:MM:SS for the most part). Actually, I might subclass it several times, once for each date format we need to support, so we can have appropriately named objects (like MyCompany::DateTime::FileStamp for DateTime objects that be default print in a format that is insertable and readable as part of a filename) to make code more expressive, and since they all subclass from DateTime, they can still interoperate while behaving (i.e., printing) in their custom fashion. Note that these are all impromptu ideas generated today after reading the DateTime faq. I haven't even written a hello world program yet, so maybe this isn't the best design for me. > > 4) Why not add the two most popular uses as convenience functions: > > my $dt = DateTime->yesterday(); > > my $dt = DateTime->tomorrow(); > > It comes back to the plethora of accessor (and constructor) methods > again. Maybe these should be in DateTime::Format::Business. Yes, you can go overboard. It's about drawing the line somewhere reasonable. I just think the line should be drawn in such a way to include yesterday and tomorrow functions. If you were to generate a list of all possible convenience functions, and sort them by what would probably be most commonly used, I'm guessing these two would float to the top. And I wouldn't say this is business specific. It's very common in just about anything related to tech administration (system or otherwise). > > Also, is anyone working on Sybase support for DateTime::Format::DBI? > > Not that I've heard of. If you'd like to give it a go we're > all here to > help. Grab one of the other DT:F:DBI modules and read the developer > docs on the website. I may give it a shot if I get the time to do it soon. I'll post here if I do, of course. -ofer
