On Fri, 10 Jan 2003, Dave Rolsky wrote: > There's a couple of thoughts I wanted to bounce off of people before I go > too much further. Please take a look at the Time::Piece API if you're not > familiar with it.
Doh, and another thought, unrelated to Time::Piece. What updating methods should the base object offer? Right now Date::ICal has the following: - add( ... ) - which also provides an overloaded '+' - subtract( ... ) - provides overloaded '-' - epoch( $epoch_time ) - offset( $tz_offset ) - this should almost certainly change to accept an object, possibly _only_ an object. Need to finish timezone module first though ;) - ical( ... ) - the docs say "Retrieves, or sets, the date on the object, using any valid ICal date/time string." However, the docs lie. It only returns a string. - jd( [ $julian_days, $julian_secs ] ) - this is not documented as an update method, but it is. It probably shouldn't be. So the question is whether things like year(), month(), hour() and so on should be updaters as well? Right now, it's just inconsistent. I see several possibilities: - _Nothing_ is an updater. There is no add() method on objects, only on the class (for overloading). The only way to "update" a date object is to replace it with a new object. - Provide a single set() method, which takes the same parameters as new(). - _All_ component accessors are updateable. So day_of_week(), day_of_year(), etc. can all be updated. A slight variation of this would be to provide set_day_of_year(), set_month(), etc. The first option has the advantage of greatly simplifying the internals. Once you calculate the julian day and seconds for an object, it just never changes. The disadvantage is that the API may seem odd to some folks. But we could still provide something like this: # same as $old_date but day of month is 5 my $new_date = $old_date->clone( day => 5 ); The last option could be _implemented_ in terms of the second (so all updates call the set() method internally). That means that implementation-wise they're about equal. And yet _another_ thought. Right now, this module occasionally warns or carps about bad parameters, and then returns undef. I'm not a big fan of warnings in modules myself. I prefer to either simply return an indication of failure (undef, 0, whatever) _or_ to throw an exception with a detailed message. But warnings simply send output to the nether regions, without any guarantee that anyone will look at it (particularly if the code is not run from a terminal). I favor exceptions myself, since I think if something is wrong, it should be considered catastrophically wrong, but I know this is a serious bone of contention. Aren't you glad I brought it up? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
