On Fri, 24 Jan 2003, Tim Bunce wrote: > Would someone do me the great favour of summarizing some things for me? > > Just the Goals and Design Principles would be great, an outline of > the API(s) would be a bonus. > > I'm particularly interested in: > Basic object API (there is going to be an object right?)
Yes, it will be an object. The API is not even close to finalized, but you can take a look at the docs for the DateTime.pm module in CVS to get an idea of where it's going: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-date-time/modules/DateTime.pm/lib/DateTime.pm?rev=1.16&content-type=text/vnd.viewcvs-markup > Extensibility (through subclasses or in other ways) > Using the extensibility well to avoid bloat of the basic object > Efficiency for common usage These three are all basically related. My goal for the core object is to have it handle the following: - represent a date & time as an object (duh ;) - be able to return various useful information about that date & time (year, month, day of week, etc.) - be able to do basic date math (add 2 days, add 1 year), with the help of DateTime::Duration -- handle leap seconds when doing date math. - be able to do time zone/offset handling, by using DateTime::TimeZone. Using the Olson DB time zone bits will be heavier weight, but there will also be an "offset-only" timezone option which lets you just say "this datetime is in -0600". The time zone parts are a little more nebulous for me right now, because the more I work on it the more I realize how complex it is. The core functionality will be extensible by simply by having a well-defined, simple API. For example, a module that provides ICal datetime format output does this: sub datetime { my $self = shift; # instance of DateTime::Format::ICal my $dt = shift; my $date = join '', $dt->year, $dt->month, $dt->day; $date .= 'T'; $date .= join '', $dt->hour, $dt->minute, $dt->second; my $tz = $dt->time_zone; # time zone object API is still very much in flux if ( ! $tz->is_floating ) { if ( $tz->offset_as_seconds == 0 ) { $date .= 'Z'; } else { $date = "TZID:" . $tz->name . ":$date"; } } return $date; } Obviously, this requires nothing from the core modules beyond what I already described. I'm hoping there will be lots of parsing/formatting modules, plus modules that calculate events (Easter, Chinese New Year, Lunar cycles, etc), and so on. As for speed, there's a couple ways to attack this. First of all, a lot of the calculations the core object will be doing can be memoized quite easily, and reset only when the object is changed (which will be infrequent in most uses). If it's still too slow, the best solution will probably be to reimplement part, or all, of the core functionality in C. The libtai64 library has already been discussed on the list. The other bottleneck that may occur is the time zone code. Since this will largely be generated from the Olson DB, it's not too much of a stretch to imagine generating XS code instead of Perl. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/