Dave Rolsky schreef:
> On Sun, 20 Jul 2003, Claus F?rber wrote:
> > So parsers could just return a DT::I object and calling code that does
> > not expect partial dates would still kinda work.
>
> The phrase "still kinda work" sets of my alarms. I think parsers that can
> return DT::Incomplete objects need to be very explicit that they do so.
> In fact, we might even want to insist that "parse_datetime" _always_
> return a complete object or fail, and then offer an additional
> "parse_incomplete_datetime" method or something like that.
I can see the logic of that.
When a module can parse both full dates and incomplete dates, and
possibly recurrences and date ranges as well, I would also implement a
"parse" module. This module returns the most logical object for a given
input; a DT or a DT::Incomplete or a DT::E::Recurrence, etc.
> > On the other hand, it would not be able to handle different calendars.
> > But then, I wonder if it's possible to just build a wrapper for all
> > DateTime::Calendar::* modules. Probably, all modules except
> > DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day'
> > like DateTime) will need an own partial class anyway.
>
> Yeah, the idea that core code should be shareable among different
> calendars is mostly bogus.
Not in this case, I think.
Of the calendars now implemented, only the Mayan calendar has no
year/month/day. The main unimplemented calendars (Hebrew, Islamic,
Persian/Jalaali, Chinese) all use a year/month/day system. If the
wrapper is careful enough, almost all of the calendars can use the same
wrapper.
And you can make DT::Incomplete even more generic:
my %cal_units = (
DateTime => [qw/year month day/],
DateTime::Calendar::Mayan => [qw/baktun katun tun uinal kin/],
...
);
Or you could specify an API:
"All calendars that want to use this wrapper (and possible a large
number of other wrappers), and that do not use the names 'year',
'month', 'day', should implement a units() method, returning an
ascending list of calendar units."
> Ignoring the Julian and Christian modules,
> most other calendars are sufficiently different that they don't really
> match up well method-wise with the core code. Java tries to shoehorn them
> all into one API and it's a horrible disaster.
Of course, it is best first to concentrate on getting a DT::Incomplete
for plain DateTime. When that is done, we can try to port it to
other calendars. And as long as it is possible without creating a mess,
if it can be done with one wrapper module for all calendars, why not?
Eugene
