Dave Rolsky <[EMAIL PROTECTED]> schrieb/wrote:
> 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.
You're right. I thought of something like this:
use DateTime;
use DateTime::Format::Foo;
my $dt = DateTime::Format::Foo->parse_datetime('10:00')
->set_base( DateTime->new(...) );
But that does not work if parse_datetime may return a complete DateTime
(which does not have set_base) either. Of course, you could also write:
my $dt = DateTime::Format::Foo->parse_datetime('10:00');
$dt = $dt->set_base( DateTime->new(...) ) if UNIVERSAL::isa($dt,
'DateTime::Incomplete');
But that's not very elegant (but it might be the most efficient
solution).
> Yeah, the idea that core code should be shareable among different
> calendars is mostly bogus. 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.
I wonder if such modules could be auto-built by DT::Incomplete. AFAICS,
you only have to know the name of the calendar module and the name of
the date fields (which could be returned by a method).
With blessing the the reference to a class name like DateTime::
Incomplete::Calendar::Whatever and generating accessor methods for that
class you're almost done.
Of course, if you want to have a more efficient representation, that's
more difficult. But that's probably only needed for ISO dates (i.e.
DateTime).
Claus
--
http://www.faerber.muc.de
